Realizar unas primeras configuraciones iniciales tras la instalación

Una vez que hemos instalado SQL Server 2005, es muy recomendable (en ocasiones imprescindible) realizar unas primeras configuraciones básicas, para poner a punto SQL Server antes de que empezar a dar servicio a los usuarios. A continuación se describen varias de estas configuraciones iniciales recomendables, o al menos, que yo suelo recomendar en los proyectos de instalación o migración de SQL Server (cada uno que tome aquellas que le puedan interesar ;-):

• Añadir discos adicionales al Cluster, para SQL Server 2005 o para Analysis Services 2005 (SSAS). Es suficiente con agregar un nuevo Recurso de Disco (Physical Disk) al Grupo de Recursos deseado, conforme se describe en el artículo Instalar y Configurar Microsoft Cluster (MSCS) en Windows Server 2003. Una vez añadido el Recurso de Disco al Grupo de Recursos deseado del Cluster, se debe crear una Dependencia del Recurso SQL Server al nuevo Recurso de Disco, o bien en el caso de Analysis Services, se debe crear una Dependencia del Recurso Analysis Services al nuevo Recurso de Disco.
  
  
• Mover las Bases de Datos de sistema (MASTER, MSSQLSYSTEMRESOURCE, MSDB, MODEL, TEMPDB). En muchos casos es recomendable mover (cambiar su ubicación física, disco y/o directorio) alguna de las bases de datos del sistema de SQL Server, como es el caso de mover TEMPDB a un disco diferente (por ejemplo, un disco más rápido), para mejorar el rendimiento y evitar algunos de los problemas del crecimiento de TEMPDB. Es posible obtener más información de las Bases de Datos del sistema, en el Artículo ¿Qué función tiene cada una de las bases de datos del sistema?. Conociendo para que sirve cada una de las bases de datos del sistema, si lo deseamos, podemos moverlas de sistio, como se explica en el artículo ¿Cómo mover las bases de datos del sistema? ¿Cómo mover MASTER, MODEL, MSDB ó TEMPDB?.
  
  
• Cambiar el tamaño inicial de TEMPDB. Una buena práctica a realizar inmediatamente después de la instalación, es dimensionar de forma apropiada la base de datos TEMPDB. El tamaño por defecto de la base de datos TEMPDB es de 8MB, con un crecimiento automático del 10%. Muchas Instancias de SQL Server requieren de un gran tamaño de TEMPDB debido a su actividad diaria (ej: ejecución de consutas, operaciones de mantenimiento, etc.). Por ello, si no tenemos dimensionada correctamente TEMPDB, se verá obligada a crecer. Pero además, no va a crecer de un único salto. Es decir, si necesitamos una TEMPDB de 20GB, crecerá desde sus 8MB de 10% en 10% hasta alcanzar los 20GB, lo cual tiene un doble impacto: Por un lado, el fichero de TEMPDB potencialmente estará muy fragmentado impactando seriamente en el rendimiento general de toda la Instancia SQL Server, y para colmo, debido a que cada vez que se inicia la Instancia de SQL Server se elimina y vuelve a crear TEMPDB, existe el riesgo de generar fragmentación en el disco utilizado por TEMPDB (es decir, que además de TEMPDB puedan encontrarse fragmentado el disco, en general). No sólo eso, sino que además, cada vez que una operación realizada por la Instancia de SQL Server requiere que TEMPDB crezca para que se pueda realizar, se produce una latencia producida por dicha operación de crecimiento del fichero de TEMPDB.
  
  La recomendación que deberemos seguir es siempre dimensionar TEMPDB. Si no somos capaces de dimensionar TEMPDB de forma apropiada, al menos darle una cantidad mínima de espacio... no sé... quizás 200MB... quizás 1GB... quizás 5GB... Claro está, que como TEMPDB se crea siempre que se inicia la Instancia de SQL Server, si dotamos a la Instancia de un fichero extraordinariamente grande sobre un disco extraordinariamente lento, estaremos impactando en el tiempo de inicio de la Instancia de SQL Server. Sin embargo, en condiciones normales, no penalizaremos el tiempo de inicio de la Instancia de SQL Servr, y mejoraremos la fragmentación y el rendimiento.
  
  Para mayor detalle, puede consultarse el Artículo Tamaño de TEMPDB ¿Cómo aumentar TEMPDB? ¿Cómo reducir TEMPDB?.
  
  
• Cambiar el Modo de Recuperación (Recovery) de MODEL (y de bases de datos de usuario que pudiésemos tener). Antes de empezar, recordar que se puede denominar Modo de Recuperación o Modo de Registro, siendo ambos términos totalmente equivalentes. Por defecto, el Modo de Recuperación (Recovery) de Model es el Modo de Recuperación Completo (Full Recovery Model), lo que implica que todas las nuevas bases de datos se crearán con éste Modo de Recuperación (excepto que se especifique otro de forma explícita), algo que puede generar problemas si no se gestiona correctamente (ej: Backups de LOG, supervisión tamaño/crecimiento del fichero de LOG, etc), como se describe en ¿Por qué crece tanto mi base de datos?. Lo recomendable (como regla general) es la utilización del Modo de Registro Completo (Full) junto con Backups de LOG periódicos. Sin embargo, en algunas instalaciones no resulta de gran utilidad el Modo de Registro Completo (Full) o se desea evitar gestionar el LOG. En este caso, puede ser interesante cambiar el Modo de Registro de Model de Completo (Full) a Sencillo (Simple). En caso contrario, puede mantenerse Model con el Modo de Registro Completo (Full).
  
  
• Crear los Inicios de Sesión miembros de la función fija sysadmin, y el resto de Inicios de Sesión. Una vez finalizada la instalación de SQL Server, debemos crear los Inicios de Sesión de los usuarios para que éstos puedan conectarse a nuestra Instancia. Especialmente importante, son los Inicios de Sesión que requieran privilegios elevados, como los utilizados por algunos Administradores de Base de Datos (DBAs), Operadores de Base de Datos, etc.
  
  
• Crear un Inicio de Sesión para el usuario utilizado para iniciar el servicio de Microsoft Cluster (Cluster Services). El usuario que inicia el servio de Microsoft Cluster (MSCS), se conecta periódicamente a SQL Server (sólo en el caso de las Instancias instaladas en Cluster, claro ;-). Por ello, mi recomendación es conceder a dicho usuario de Directorio Activo, un Inicio de Sesión exclusivo, al cual no es necesario conceder ningún permiso adicional en SQL Server. Si no creamos este Inicio de Sesión, el usuario utilizado para iniciar el servicio de Microsoft Cluster (MSCS) accederá a SQL Server a través de BUILTIN\Administrators ya que dicho usuario es miembro del Grupo local Administradores en cada Nodo del Cluster (esto es requisito del Producto, así que, seguro que será así). Sin embargo, como comento un poco más adelante, mi recomendación es eliminar el Inicio de Sesión BUILTIN\Administrators, por lo que deberemos crear este Inicio de Sesión para garantizar que el usuario que inicia el servicio de Microsoft Cluster (MSCS) pueda conectarse a SQL Server (excepto que pertenezca a algún otro Grupo de Directorio Activo con permisos de acceso a SQL Server).
  
  
• Eliminar el Inicio de Sesión BUILTIN\Administrators. Ya han sido muchas las instalaciones (de hecho, todas ;-) en las cuales me he encontrado la existencia del Inicio de Sesión BUILTIN\Administrators. Mucha gente piensa que el Inicio de Sesión BUILTIN\Administrators no se puede eliminar, lo cual es erróneo. En cualquier caso, el problema no es éste. El problema es que en muchas instalaciones a través del Inicio de Sesión BUILTIN\Administrators acceden usuarios no deseados (ej: Administradores del Dominio) con privilegios elevados (sysadmin) a la Instancia de SQL Server. Por ello, mi recomendación es eliminar el Inicio de Sesión BUILTIN\Administrators, y de este modo, eliminar un grave problema de seguridad (ojo, que en muchas instalaciones, hay casi más usuarios Administradores del Dominio, que en cualquier otro Grupo de Directorio Activo ;-).
  
  
• Configurar el puerto TCP deseado para cada instancia de motor de base de datos. Por defecto, una Instancia por Defecto de SQL Server 2005 queda configurada durante la instalación para escuchar en el puerto TCP-1433, sin embargo, las Instancias con Nombre quedan configuradas durante el proceso de instalación para escuchar en puertos TCP dinámicos, por lo tanto, cada vez que se inicie la Instancia puede que escuche en un puerto diferente. Esta situación puede resultar problemática, por un lado desde el punto de vista de la seguridad (el hecho de escuchar en un puerto TCP fácilmente predecible, puede facilitar la existencia de ataques informáticos), y por otro lado porque algunas aplicaciones que se conectan a SQL Server requieren que se les facilite el puerto TCP en el que escucha la instancia de SQL Server. Además, si es necesario acceder a SQL Server a través de un Firewall, será necesario utilizar un puerto TCP estático en la Instancia de SQL Server, para así poder definir la correspondiente regla de acceso en el Firewall. Por todo esto, suele ser recomendable cambiar el Puerto TCP de la Instancia de SQL Server 2005 después de su instalación.
  
  ¿Cómo saber en qué puerto TCP está escuchando SQL Server? ¿Cómo configurar el puerto TCP de escucha una Instancia de SQL Server? Para responder a éstas preguntas, puede leerse el artículo ¿En qué puerto TCP escucha SQL Server 2005? ¿Cómo cambiar o configurar el puerto TCP de escucha de una Instancia de SQL Server 2005?
  
  
• Configurar límites de memoria de cada instancia de SQL Server 2005. Es posible configurar las opciones de configuración min server memory y max server memory de una Instancia de SQL Server, para configurar la cantidad de memoria posible que puede utilizar el Buffer Cache de SQL Server. El Buffer Cache es la zona de memoria utilizada por SQL Server para almacenar las páginas de datos. Es decir, si SQL Server ejecuta una consulta, dicha consulta accede a disco para leer las páginas de datos de los ficheros de la base de datos. Dichas páginas de datos, se almacenan temporalmente en memoria, de tal modo, que una segunda consulta de SQL Server que requiera acceder a dichas páginas de datos, no necesitará volver a leerlas del disco (lectura física), sino que sencillamente las leera de memoria (del Buffer Cache: lectura lógica).
  
  Por defecto, SQL Server gestiona de forma automática la memoria, tomando toda la memoria que necesite pero sin llegar a producir que el Sistema Operativo incurra en paginación. Este es el comportamiento predeterminado y el recomendado, especialmente en instalaciones sobre máquinas exclusivas para SQL Server. Sin embargo, si además de una Instancia de SQL Server conviven más servicios en la misma máquina (ej: múltiples Instancias de SQL Server, Analysis Services, etc), es posible utilizar la opción max server memory para evitar guerras de recursos entre la Instancia de SQL Server y otros servicios sobre la misma máquina. Esta configuración es delicada, ya que una Instancia de SQL Server sin suficiente memoria incurriría en una pérdida de rendimiento considerable debida al aumento de operaciones físicas de acceso a disco. Puede leerse más detales en el artículo ¿Por qué aumenta tanto la memoria RAM consumida por SQL Server?.
  
  Personalmente soy partidario de mantener la configuración por defecto de SQL Server, es decir, que se gestione la memoria cómo le venga en gana. La principal excepción que suelo contemplar (que no la única), es cuando existe múltiples Instancias en la misma máquina, ya que me he encontrado con problemas de que una Instancia de SQL Server toma la mayoría de la memoria, y el resto de Instancias toman muy poquita memoria, incurriendo en una caída tremenda de rendimiento. Un caso real, se trataba de una máquina con múltiples Instancias (ej: Desarrollo, Pruebas Integradas, Pre-Producción, etc.). Como la mayoría de actividad se producía sobre la Instancia de Desarrollo, era dicha Instancia la que rápidamente empezaba a llevarse la memoria de la máquina, de tal modo que las Instancias de Pruebas Integradas y Pre-Producción ofrecían un rendimiento pésimo, por lo que las pruebas que se realizaban en dichos entornos quedaban totalmente desvirtuadas. La solución es tan sencilla como limitar la memoria utilizada por la Instancia SQL Server de Desarrollo (y a ser posible, también limitar el resto), para garantizar que todas las Instancias de SQL Server disponen de una cantidad de memoria suficiente para trabajar.
  
  
• Crear o modificar nombres DNS para acceder a SQL Server (un Nombre DNS para cada Instancia). Habitualmente para conectarnos a una Instancia de SQL Server 2005 especificamos el Nombre NetBIOS de la máquina (ej: ServerName) o bien el Nombre NetBIOS de la máquina y el nombre la Instacia para el caso de Instancias con Nombre (ej: ServerName\InstanceName). Personalmente, en muchos casos recomiendo utilizar un Nombre DNS en lugar del Nombre NetBIOS de la máquina, lo que me ha servido en varias ocasiones sobre entornos de Producción reales.
  
  Por ejemplo, en caso de la pérdida del servidor (como contingencia), es posible montar un servidor alternativo con SQL Server, recuperar sobre el mismo las bases de datos, y cambiar el Nombre DNS para que apunte al nuevo servidor mientras se recupera el servidor original. Si no utilizásemos DNS, podríamos montar éste servidor adicional, pero deberíamos cambiar en todas las aplicaciones los datos de conexión para utilizar el Nombre NetBIOS de la nueva máquina, y una vez recuperado el servidor original, volver a repetir dicha tarea a la inversa. Teniendo en cuenta las aplicaciones que pueden llegar a utilizar SQL Server en una empresa, incluyendo hojas Excel que accedan a SQL Server, Scripts VBS que accedan a SQL Server, procesos de carga de herramientas ETL, etc., resulta muy laborioso.
  
  La utilización de Nombres DNS también me ha servido para Migrar servidores SQL Server y para consolidar o separar Instancias de SQL Server, pudiendo preparar el nuevo servidor tranquilamente, y cortar el servicio sólo y exclusivamente para copiar datos de usuario y cambiar el Nombre DNS para apuntar al nuevo servidor, consiguiendo periodos de caída de servicio muy pequeños en procesos de Migración de SQL Server y en Consolidaciones o Segraciones de Instancias.
  
  Del mismo modo que os he comentado lo anterior, en caso de utilizar algunas funcionalidades como la Replicación de SQL Server recomiendo NO utilizar Nombres DNS, y utilizar Nombres NetBIOS de Máquina. La Replicación de SQL Server es un caso muy especial, y aunque sus detalles caen fuera del alcance de este Artículo, si es cierto que la Replicación de SQL Server NO se puede Migrar de una máquina a otra, por lo que nuestro invento del Nombre DNS pierde su utilidad.
  
  
• Agregar usuarios al rol de administradores (server administrators) de Analysis Services (SSAS). Es recomendable especificar los usuarios de Windows (bueno... más bien usuarios de Directorio Activo) con privilegios de administración de la instancia de Analysis Services (SSAS), al finalizar la instalación de SSAS. Dichos usuario tendrán privilegios elevados sobre todas las bases de datos de Analysis Services, y sobre la propia instancia de Analysis Services (ej: ver y configurar las propiedades de la instancia de Analysis Services, etc.). Esta configuración la podremos realizar desde el diálogo Propiedades de la instancia de Analysis Services, en SQL Server Management Studio (SSMS).
  
  
• Configurar el Log de Consultas (Query Log) de Analysis Services (SSAS). En Analysis Services 2005 por defecto no está configurado el Log de Consultas (QueryLog), el cual es posible configurar desde el diálogo Propiedades de la instancia de Analysis Services, en SQL Server Management Studio (SSMS). En particular, será necesario revisar y/o modificar las propiedades Log \ QueryLog \ CreateQueryLogTable (especifica si deseamos que Analysis Services cree la tabla del QueryLog, si esta no existe en la base de datos especificada), Log \ QueryLog \ QueryLogConnectionString (permite especificar la cadena de conexión a la base de datos SQL Server deseada para almacenar el Log de Consultas de SQL Server - QueryLog), Log \ QueryLog \ QueryLogSampling (el valor por defecto de esta propiedad es 10, que indica que una de cada diez consultas será registrada en el QueryLog), y Log \ QueryLog \ QueryLogTableName (especifica el nombre deseado para la tabla utilizada para almacenar el Log de Consultas de Analysis Services - QueryLog). La configuración del Log de Consultas (QueryLog) de Analysis Services permite poder utilizar la utilidad Usage-Based Optimization Wizard. Debe tenerse en cuenta, que la configuración del Log de Consultas (QueryLog) de Analysis Services implica la creación de una tabla en una base de datos SQL Server, y sobre dicha tabla se almacenará el Log de Consultas (QueryLog) de Analysis Services (SSAS), con el correspondiente coste de Almacenamiento.
  
  

Puede ser necesario realizar alguna configuración adicional en Directorio Activo, relacionada con la Autenticación y Delegación de Kerberos. Ver los artículos Configurar Analysis Services, MOSS y Kerberos y Cannot Generate SSPI context y setspn.exe en SQL Server

Personalmente, antes de iniciar la instalación sobre un entorno real (ya sea para Producción, Desarrollo, Pre-Producción, Pruebas Integradas, Calidad, etc.) considero muy importante la realización de un Laboratorio donde probar y documentar la instalación o migración de SQL Server, y además, sobre el mismo desarrollar y probar un Plan de Contingencia. Este ejercicio previo, nos aportará una gran ventaja: cuando realicemos la instalación real y empecemos a dar servicio a usuarios, también estaremos preparados para devolver el servicio lo antes posible ante las situaciones previstas. En particular, sería recomendable considerar:

• Plan de Contingencias de SQL Server 2005.
• Plan de Contingencias de Analysis Services 2005 (SSAS).
• Plan de Contingencias de Integration Services 2005 (SSIS).
• Plan de Contingencias de Windows Server 2003.
• Plan de Contingencias de Microsoft Cluster (MSCS).

Además, es muy recomendable que incluir un Plan de Formación para Administradores y Operadores previo a la puesta en producción de un nuevo servicio, como es el caso de SQL Server 2005, Analysis Services 2005 (SSAS), Integration Services 2005 (SSIS), Windows Server 2003, y Microsoft Cluster (MSCS). Mi recomendación, más que acudir a cursos de calendario de empresas de formación (que también es una posibilidad, y buena), es la elaboración de un Plan de Formación a medida por personal de la propia instalación (ya sea personal interno o externo) que conozca las infraestructuras, la organización de los distintos departamente, el hardware y comunicaciones utilizados, el propio personal (vamos, los compañeros ;-), etc. Suele ser recomendable que este trabajo sea realizado por un Consultor Externo que conozca bien la instalación, principalmente, por la capacidad de aportar una visión externa y su experiencia en otras instalaciones, pero vamos, que dependiendo de qué consultor...

Por supuesto, después de toda instalación es una buena práctica generar un documento de configuración, especificando datos como nombres de máquinas, directorios utilizados, nombres y alias DNS utilizados, Direcciones IP, nombres de Instancias, Intercalación de cada Instancia, etc.