INFORMACIÓN DEL DOCUMENTO

Tabla de contenido
1. Requisitos de SQL Server...............................................................................................3
2. Configuración de Intercalación de SQL Server..............................................................3
3. Configuración de Firewall..............................................................................................3
4. Consideración de Capacidad y Almacenamiento............................................................4
5. SQL Server Always On...................................................................................................5
5.1 Recomendaciones para las replicas de disponibilidad.................................................6
5.2 Cadena de Varias Sub Redes........................................................................................7
6. Optimización de SQL Server..........................................................................................7
6.1 Tamaño de la unidad de asignación de NTFS..............................................................8
6.2 Reserva de Memoria....................................................................................................8
6.3 Optimizar Tempdb.......................................................................................................9
6.4 Máximo Grado de Paralelismo..................................................................................10
6.5 Tamaño Inicial de las Bases de Datos........................................................................11
6.6 Crecimiento Automático de las Bases de Datos.........................................................11
6.7 Directiva de Cluster....................................................................................................12
6.8 Virtualización de SQL Server.....................................................................................13
6.9 Always On, y el Modelo de Recuperación y Backups...............................................13
7. Optimización de SQL Server Reporting Services.........................................................13
8. Seguridad y Permisos de Usuarios................................................................................14
9. Plan de Administración.................................................................................................14
1. Requisitos de SQL Server

Al planear el diseño de Bases de Datos en SQL Server se deben tener en cuenta consideraciones
de hardware y software:

 Se recomienda ejecutar SQL Server en equipos con el formato de archivo NTFS.

 Debe haber al menos 1024 MB de espacio libre en disco para la base de datos operativa y
de almacenamiento de datos. Esto se aplica en el momento de creación de la base de datos
y es probable que el espacio en disco requerido aumente considerablemente tras la
instalación.

 Se requiere .NET Framework 4.

 Servidor de informes no es compatible con Windows Server Core.

 Mantener la actualización del último Service Pack de la versión instalada, Para SQL Server
2016 existen dos Service Pack, El primero emitido el 16/11/2016 y el ultimo emitido el
24/04/2018 con soporte hasta el 14/07/2026.

2. Configuración de Intercalación de SQL Server.

Las reglas de intercalación base, abarcan lo siguiente:

 Las reglas de ordenación y comparación que se aplican cuando se especifica la
ordenación del diccionario. Las reglas de ordenación se basan en el alfabeto o en el
idioma.
 La página de códigos que se usa para almacenar datos varchar.

Las intercalaciones de SQL Server y Windows que se configuren deben ser compatibles con las
aplicaciones usadas por el cliente. Para este caso se deja las mismas intercalaciones que se
tienen configuradas.

SQL_Latin1_General_CP850_CI_AI

3. Configuración de Firewall

Si va a diseñar una implementación distribuida que requiera grupos de disponibilidad de SQL

Always On para proporcionar funcionalidad de conmutación por error para las bases de datos de
aplicaciones, hay ajustes de configuración del firewall que se deben incluir en la estrategia de
seguridad de firewall.
La tabla siguiente le ayuda a identificar los puertos de firewall necesarios para SQL Server que se
deben permitir como mínimo para que los roles de servidor en el grupo de administración para que
las aplicaciones se puedan comunicar correctamente.

Escenario Puerto Direction Rol

 SQL Server que hospeda TCP 1433 * Entrante servidor de administración y
bases de datos de aplicaciones consola web (para
Application Advisor y
Diagnóstico de aplicaciones)

Servicio SQL Server Browser UDP 1434 Entrante Servidor de administración

Conexión de administración TCP 1434 Entrante Servidor de administración
dedicada de SQL Server
Otros puertos usados por TCP 135 Entrante Servidor de administración
SQL Server
- Llamadas a procedimiento
remoto de Microsoft (MS RPC)
- Instrumental de
administración de Windows
(WMI)
- Coordinador de
transacciones distribuidas de
Microsoft (MS DTC)
Escucha de grupo de Puerto configurado Entrante Servidor de administración
disponibilidad de SQL Server por el administrador
Always On

SQL Server Reporting TCP 80 Entrante servidor de administración y

Services que hospeda el (predeterminado)/443 consola del operador
servidor de informes de (SSL)
Operations Manager

Aunque el puerto estándar de la instancia predeterminada del motor de base de datos es TCP
1433, cuando se crea una instancia con nombre en un servidor de SQL Server independiente o se
ha implementado un grupo de disponibilidad de SQL Always On, se definirá un puerto
personalizado y se incluirá como referencia para que configure los firewalls correctamente y
especifique esta información durante la instalación. En el documento de Check List y en las hojas
de vida están registrados los puertos utilizados en la migración.
4. Consideración de Capacidad y Almacenamiento.

SQL Server tiene acceso a datos y archivos de registro con patrones de e/s muy diferentes. El
acceso a archivos de datos es aleatorio mientras que el acceso al archivo de registro de
transacciones es secuencial. El almacenamiento en disco giratorio requiere la recolocación del
cabezal de disco para un acceso aleatorio de lectura y escritura. Por lo tanto, los datos
secuenciales son más eficaces que el acceso aleatorio a datos. Separar los archivos que tienen
diferentes patrones de acceso ayuda a minimizar los movimientos del cabezal de disco y optimiza
así el rendimiento del almacenamiento.
Utilice RAID 10 para los archivos binarios de usuario, datos, registros y TempDB para obtener el
mejor rendimiento y disponibilidad.

TempDB Sizing

Inflar de forma proactiva los archivos TempDB a su tamaño completo para evitar la fragmentación
del disco.
La contención de la página puede producirse en páginas GAM, SGAM o PFS cuando SQL tiene
que escribir en páginas del sistema especiales para asignar nuevos objetos. Los pestillos protegen
(bloquean) estas páginas en la memoria. En un servidor SQL ocupado, puede tardar mucho tiempo
en obtener un bloqueo en una página del sistema en tempdb. Esto da como resultado tiempos de
ejecución de consultas más lentos y se conoce como contención de pestillo.

Una buena regla de oro para crear archivos de datos de tempdb:

Para < = 8 núcleos
Archivos de datos Tempdb = # de núcleos
Para > 8 núcleos
8 los archivos de datos Tempdb

A partir de SQL Server 2016, el número de núcleos de CPU visibles para el sistema operativo se
detecta automáticamente durante la instalación y, en función de ese número, SQL calcula y
configura el número de archivos de tempdb necesarios para obtener un rendimiento óptimo. La
configuración automática de los archivos de tempdb de acuerdo con el número de núcleos de CPU
disponibles es un gran paso adelante y felicitaciones a Microsoft por la introducción de esta gran
nueva característica.
Otra cosa que vale la pena ver en relación con tempdb es la marca de traza 1118 (solo extensión
completa)

Microsoft KB2154845 aconseja que Trace Flag 1118 puede ayudar a reducir la contención de
asignación en tempdb. El indicador de traza 1118 indica a SQL Server que evite las "extensiones
mixtas" y que use "extensiones completas". https://technet.Microsoft.com/en-us/library/ms190969 (v
= SQL. 105). Aspx

Con el indicador de traza 1118 habilitado cada objeto recién asignado en cada base de datos en la
instancia obtiene su propio privado 64kb de datos. El impacto es mayor en tempdb, donde se crean
la mayoría de los objetos.

En el documento de Entrega de Bases de Datos, se describe la forma en que se organizaron los

Data files y la distribución de los discos por instancia.

5. SQL Server Always On.

Para las aplicaciones de Servientrega, es preferible usar SQL Always On en vez de la conmutación
por error para proporcionar alta disponibilidad para bases de datos. En un grupo de disponibilidad
Always On se pueden hospedar todas las bases de datos excepto la instalación del modo nativo de
Reporting Services, que usa dos bases de datos para separar el almacenamiento de datos
persistentes de los requisitos de almacenamiento temporal.
Para configurar un grupo de disponibilidad, deberá implementar un clúster de Clústeres de
conmutación por error de Windows Server (WSFC) para hospedar la réplica de disponibilidad y
habilitar Always On en los nodos de clúster. Luego, puede agregar las base de datos del negocio
como una base de datos de disponibilidad.

Requisito Vínculo

Asegúrese de que el sistema no es un No se admiten grupos de disponibilidad en los

controlador de dominio.
Procure que cada equipo ejecute Windows
Server 2012 o una versión posterior.
Asegúrese de que cada equipo es un nodo
en un WSFC.
controladores de dominio.
Requisitos de hardware y software para instalar SQL
Server 2016
Clústeres de conmutación por error de Windows Server
(WSFC) con SQL Server
Asegúrese de que el WSFC contiene los Un nodo de clúster puede hospedar una réplica para un
nodos suficientes para admitir las grupo de disponibilidad. El mismo nodo no puede
configuraciones de grupo de disponibilidad. hospedar dos réplicas del mismo grupo de
disponibilidad. El nodo del clúster puede participar en
varios grupos de disponibilidad, con una réplica de cada
grupo.

5.1 Recomendaciones para las replicas de disponibilidad

 Sistemas comparables: En el caso de un grupo de disponibilidad determinado, todas las

réplicas de disponibilidad se deben ejecutar en sistemas comparables que puedan
controlar cargas de trabajo idénticas.

 Adaptadores de red dedicados: Para obtener el mejor rendimiento, utilice un adaptador

de red (tarjeta de interfaz de red) dedicado para Grupos de disponibilidad AlwaysOn.

 Espacio suficiente en disco: todos los equipos en los que una instancia del servidor
hospede una réplica de disponibilidad deben tener suficiente espacio en disco para todas
las bases de datos del grupo de disponibilidad. Tenga en cuenta que según crecen las
bases de datos principales, las correspondientes bases de datos secundarias aumentan la
misma cantidad.

5.2 Cadena de Varias Sub Redes.

Las solicitudes de conexión de cliente desde los servidores de administración superarán el

tiempo de espera de la conexión al agente de escucha del grupo de disponibilidad. Esto se
debe a que un grupo de disponibilidad tiene un nombre de agente de escucha (conocido como
nombre de red o punto de acceso de cliente en el administrador de clústeres de WSFC) que
depende de varias direcciones IP de distintas subredes, como cuando se realiza una
implementación en una configuración de conmutación por error entre sitios.
El método recomendado para solucionar esta limitación es que realice lo siguiente cuando
haya implementado los nodos del servidor en el grupo de disponibilidad de un entorno con
varias subredes:

1. Establezca el nombre de red del agente de escucha del grupo de disponibilidad para que
solo registre una única dirección IP activa en DNS.
2. Configure el clúster para que use un valor de TTL bajo para el registro de DNS registrado.

Esta configuración permite que se realice una recuperación y una resolución del nombre del
clúster con la nueva dirección IP más rápidas cuando se realiza una conmutación por error en
un nodo de una subred distinta.

6. Optimización de SQL Server.

En general, la experiencia de implementación anterior con clientes indica que los problemas de
rendimiento no son debido a un gran uso de recursos (es decir, del procesador o de la memoria) de
SQL Server, sino que están relacionados directamente con la configuración del subsistema de
almacenamiento. Los cuellos de botella de rendimiento a menudo se atribuyen a no seguir las
siguientes instrucciones de configuración recomendada con el almacenamiento aprovisionado para
la instancia de base de datos de SQL Server. Dichos ejemplos son:
  Asignación insuficiente de ejes para que el LUN admita los requisitos de E/S de Operations
Manager.
 Hospedaje en el mismo volumen de registros de transacciones y archivos de bases de
datos. Estas dos cargas de trabajo tienen características de E/S y latencia diferentes.
 Configuración incorrecta de TempDB, con respecto a la ubicación, tamaño, etc.
 Error de alineación de particiones de disco de los volúmenes que hospedan los registros
de transacciones y archivos de la base de datos y TempDB.
 Omisión de la configuración básica de SQL Server, como el uso de AUTOGROW para los
archivos de registro de transacciones y de base de datos, configuración de MAXDOP para
el paralelismo de consultas, creación de varios archivos de datos TempDB por núcleo de
CPU, etc.

Los servidores de base de datos suelen estar muy limitados en E/S debido a la actividad de lectura
y escritura de la base de datos y el procesamiento de registro de transacciones rigurosos. El patrón
de comportamiento de E/S de las bases de datos normalmente es de 80 % de escrituras y 20 % de
lecturas. Como resultado, una configuración incorrecta de los subsistemas de E/S puede provocar
un rendimiento y funcionamiento deficientes de los sistemas de SQL Server.

6.1 Tamaño de la unidad de asignación de NTFS.

La alineación de volumen, conocida comúnmente como la alineación de sectores, se debe

realizar en el sistema de archivos (NTFS) cada vez que se cree un volumen en un dispositivo
RAID. Si no lo hace, puede provocar una degradación significativa del rendimiento, lo que
suele ser el resultado de un error de alineación de partición con límites de unidad de bandas.
También puede ocasionar un error de alineación de caché del hardware, lo que provocará un
uso poco eficaz de la caché de matriz. Al formatear la partición que se usará para los archivos
de datos de SQL Server, se recomienda que use un tamaño de unidad de asignación de 64 KB
(es decir, 65 536 bytes) para datos, registros y tempdb. Pero tenga en cuenta que si usa
tamaños de unidades de asignación mayores de 4 KB no podrá usar la compresión NTFS en el
volumen. Aunque SQL Server admite datos de solo lectura en los volúmenes comprimidos, no
se recomienda hacerlo.
6.2 Reserva de Memoria.
SQL
No es tarea sencilla establecer la cantidad adecuada de memoria física y procesadores para
asignar en el servidor Windows para SQL Server 2014 y 2016.
Aunque la calculadora de tamaño proporcionada por el grupo de producto, que se basa en
pruebas realizadas en un entorno de laboratorio que pueden coincidir o no con la carga de
trabajo y configuración típicas en la realidad, proporciona instrucciones basadas en la escala
de la carga de trabajo (es decir, 500 sistemas, 1000 sistemas, etc.), el valor que indica a
menudo se pone en entredicho. Sirve como recomendación inicial con la que partir, pero no es,
ni puede considerarse, la configuración final.

De forma predeterminada, SQL Server puede cambiar de forma dinámica los requisitos de
memoria, en base a los recursos del sistema disponibles. El valor predeterminado de min
server memory es 0 y el valor predeterminado de max server memory es 2147483647. La
cantidad mínima de memoria que puede especificar para max server memory es 16 megabytes
(MB). Varios problemas de rendimiento y relacionados con la memoria se deben a que el
cliente no estableció un valor para Max. server memory, y no lo hace porque no sabe qué
poner. Muchos otros factores influyen en la cantidad máxima de memoria que puede asignar a
SQL para asegurar que el sistema operativo tiene memoria suficiente para admitir los demás
procesos en ejecución en dicho sistema, como la tarjeta de HBA, agentes de administración,
examen en tiempo real del antivirus, etc. De lo contrario, el sistema operativo y SQL se
paginarán al disco y, después, se producirán incrementos de E/S del disco, reducción adicional
del rendimiento y creación de un efecto dominó que se hará patente el rendimiento de las
bases de datos.
Empiece primero por reservar 1 GB de RAM para el sistema operativo, 1 GB para cada 4 GB
de RAM instalada de 4 a 16 GB y 1 GB para cada 8 GB de memoria RAM instalada por encima
de 16 GB de RAM. Después, supervise el contador de rendimiento de Memoria/MBytes
disponibles de Windows para determinar si puede aumentar la memoria disponible para SQL
Server por encima del valor inicial.

A medida que más clientes avanzan hacia la virtualización de SQL Server en su entorno, esta
pregunta es más relevante para determinar cuál es la cantidad mínima de memoria que
necesita SQL Server para ejecutarse en una máquina virtual. Lamentablemente, no hay
ninguna manera para calcular cuál es la cantidad de memoria ideal para una determinada
instancia de SQL Server podría ser, debido a que SQL Server está diseñado para almacenar
datos en caché en el grupo de búferes y normalmente usará toda la memoria que le pueda dar.
Una de las cosas que se debe tener en cuenta cuando intenta reducir la memoria asignada a
una instancia de SQL Server es que finalmente llegará a un punto donde se sacrificará la
memoria inferior para obtener acceso de E/S a un disco superior.

Si necesita averiguar la configuración ideal para la memoria de SQL Server en un entorno que
se haya sobre aprovisionado, la mejor manera de intentar hacerlo es empezar por realizar una
línea base del entorno y las métricas de rendimiento actuales. Los contadores para la
supervisión inicial incluyen los siguientes:

 SQL Server:Buffer Manager\Duración prevista de la página

 SQL Server:Buffer Manager\Lecturas de página/seg.
 Disco físico\Lecturas de disco/seg.
6.3 Optimizar Tempdb.

El tamaño y la ubicación física de la base de datos tempdb pueden afectar al rendimiento de

las bases de datos. Por ejemplo, si el tamaño definido para tempdb es demasiado pequeño,
parte de la carga de procesamiento del sistema puede que se rellene con el crecimiento
automático de tempdb hasta el tamaño necesario para admitir la carga de trabajo cada vez que
se reinicie la instancia de SQL Server. Para conseguir un rendimiento óptimo, se recomienda la
siguiente configuración para tempdb en un entorno de producción:

 Establezca el modelo de recuperación de tempdb en SIMPLE. Este modelo recupera

automáticamente espacio de registro para mantener bajos los requisitos de espacio.

 Asigne espacio previamente para todos los archivos de tempdb estableciendo el tamaño
del archivo en un valor lo suficientemente grande como para dar cabida a una carga de
trabajo típica del entorno. Evita que tempdb se expanda con demasiada frecuencia, lo
que puede afectar al rendimiento. Se puede establecer la base de datos tempdb en
crecimiento automático, pero esto debería usarse para aumentar el espacio en disco
para las excepciones imprevistas.

 Cree tantos archivos como sea necesario para maximizar el ancho de banda del disco. El
uso de varios archivos reduce la contención de almacenamiento de tempdb y produce
una escalabilidad mejorada. Pero no cree demasiados archivos, ya que esto puede
reducir el rendimiento y aumentar el trabajo administrativo. Como norma general, cree
un archivo de datos para cada procesador lógico en el servidor (teniendo en cuenta los
valores de máscara de afinidad) y, después, ajuste el número de archivos hacia arriba o
hacia abajo según sea necesario. Como regla general, si el número de procesadores
lógicos es menor o igual a 8, use el mismo número de archivos de datos que
procesadores lógicos. Si el número de procesadores lógicos es mayor que 8, use 8
 archivos de datos y después, si se mantiene la contención, aumente el número de
archivos de datos en múltiplos de 4 (hasta el número de procesadores lógicos) hasta
que la contención se reduzca y alcance niveles aceptables o realice cambios en el
código o la carga de trabajo. Si no se reduce la contención, tendrá que aumentar más el
número de archivos de datos.

 Haga que cada archivo de datos tenga el mismo tamaño. Esto permite obtener el máximo
rendimiento de relleno proporcional. El tamaño uniforme de archivos de datos es
importante porque el algoritmo de relleno proporcional se basa en el tamaño de los
archivos. Si se crean archivos de datos con distintos tamaños, el algoritmo de relleno
proporcional intenta usar el archivo más grande para las asignaciones de página GAM
en lugar de distribuir las asignaciones entre todos los archivos, con lo que frustra el
propósito de crear varios archivos de datos.

 Coloque la base de datos tempdb en un subsistema de E/S rápido con unidades de estado
sólido para obtener un rendimiento óptimo. Cree bandas en disco si hay muchos discos
conectados directamente.

 Coloque la base de datos tempdb en discos diferentes de los que usan las bases de datos
de usuario.

6.4 Máximo Grado de Paralelismo.

La opción de configuración del grado máximo de paralelismo de Microsoft SQL Server

(MAXDOP) controla el número de procesadores que se usan para la ejecución de una consulta
en un plan paralelo. Esta opción determina los recursos de proceso y subproceso que se usan
para los operadores de plan de consultas que realizan el trabajo en paralelo. Dependiendo de
si SQL Server está configurado en un equipo multiproceso simétrico (SMP), un equipo de
acceso a memoria no uniforme (NUMA) o procesadores habilitados para hiperproceso, tendrá
que configurar adecuadamente la opción de grado máximo de paralelismo.
Cuando SQL Server se ejecuta en un equipo con más de un microprocesador o CPU, detecta
el mejor grado de paralelismo, es decir, el número de procesadores usados para ejecutar una
única instrucción, para cada ejecución de planes paralelos. De forma predeterminada, el valor
para esta opción es 0, lo que permite a SQL Server determinar el grado máximo de
paralelismo.
Las consultas y procedimientos almacenados predefinidos en Operations Manager, ya que se
relaciona con la base de datos operativa, de almacenamiento de datos e incluso de auditoría,
no incluyen la opción MAXDOP, puesto que no hay ninguna manera durante la instalación de
consultar dinámicamente cuántos procesadores se presentan en el sistema operativo ni intenta
codificar el valor de esta configuración, lo que podría tener consecuencias negativas cuando se
ejecute la consulta.
La opción de configuración de grado máximo de paralelismo no limita el número de
procesadores que usa SQL Server. Para configurar dicho número, use la opción de
configuración de máscara de afinidad.
 Para servidores que usan más de ocho procesadores, use la siguiente configuración:
MAXDOP=8
 Para servidores que usan ocho procesadores o menos, use la siguiente configuración:
MAXDOP=0 to N. Nota: En esta configuración, N representa el número de procesadores.
 Para servidores con NUMA configurado, MAXDOP no debería superar el número de CPU
que se asignan a cada nodo de NUMA.
 Para servidores que tienen habilitado el hiperproceso, el valor de MAXDOP no debería
superar el número de procesadores físicos.
 Para servidores que tienen NUMA configurado y habilitado el hiperproceso, el valor de
MAXDOP no debería superar el número de procesadores físicos por nodo de NUMA.
6.5 Tamaño Inicial de las Bases de Datos.

El tamaño inicial de la base de datos, como sugiere el asistente para ajuste de tamaño, se
debe asignar a un tamaño previsto para reducir la fragmentación y la correspondiente
sobrecarga, que se puede especificar para las bases de datos operativas y de almacenamiento
de datos durante la instalación. Si durante la instalación no hay suficiente espacio de
almacenamiento disponible, las bases de datos se pueden expandir más adelante mediante
SQL Management Studio y, después, volver a indexar posteriormente para desfragmentar y
optimizar según corresponda. Esta recomendación también se aplica a la base de datos de
ACS.
La supervisión proactiva del crecimiento de la base de datos operativa y de almacenamiento de
datos debe realizarse en un ciclo diario o semanal. Esto será necesario para identificar
incrementos repentinos de crecimiento significativos y empezar a solucionar problemas para
determinar si está provocado por un error en un flujo de trabajo del módulo de administración
(es decir, regla de detección, regla de recopilación de rendimiento o de evento o reglas de
alerta o monitor) o cualquier otro síntoma con un módulo de administración no identificado
durante las pruebas y la fase de control de calidad del proceso de administración de versiones.

6.6 Crecimiento Automático de las Bases de Datos

Cuando el tamaño de archivo de las bases de datos que se ha reservado en el disco se llena,
SQL Server puede aumentar automáticamente el tamaño, en un porcentaje o una cantidad fija.
Además, se puede configurar un tamaño máximo de base de datos, para evitar que se llene
todo el espacio disponible en disco. De forma predeterminada, las bases de datos no estan
configuradas con la función de crecimiento automático habilitada, sino que solo lo están las
bases de datos de ACS y de almacenamiento de datos.

Confíe en el crecimiento automático solo como medida de contingencia para el crecimiento

imprevisto. El crecimiento automático presenta una reducción del rendimiento que se debe
tener en cuenta cuando se trabaja con una base de datos altamente transaccional. La
reducción del rendimiento incluye:

 Fragmentación del archivo de registro o base de datos si no proporciona un incremento de

crecimiento adecuado.

 Si se ejecuta una transacción que requiere más espacio de registro del que está disponible
y ha activado la opción de crecimiento automático del registro de transacciones de esa
base de datos, el tiempo que tarde en finalizar la transacción incluirá el tiempo que tarda
el registro de transacciones en crecer la cantidad configurada.

 Si ejecuta una transacción grande que requiere que el registro crezca, otras transacciones
que requieran una escritura en el registro de transacciones también tendrán que esperar
hasta que se complete la operación de crecimiento.

Si se combinan las opciones de crecimiento automático y autorreducción, puede crear una

sobrecarga innecesaria. Asegúrese de que los umbrales que desencadenan las operaciones
de crecimiento y reducción no provocarán cambios de tamaño frecuentes. Por ejemplo, puede
ejecutar una transacción que hace que el registro de transacciones crezca en 100 MB en el
momento en que confirma. Algún tiempo después, se inicia la autorreducción y reduce el
registro de transacciones en 100 MB. Entonces, vuelve a ejecutar la misma transacción y esta
provoca que el registro de transacciones vuelva a crecer 100 MB. En el ejemplo, está creando
un trabajo innecesario y probablemente una fragmentación del archivo de registro, y cualquiera
de ellas puede afectar negativamente al rendimiento.

Se recomienda configurar estos dos valores con cuidado. En realidad, la configuración

específica depende del entorno. Por lo general, se recomienda aumentar el tamaño de la base
de datos en una cantidad fija para reducir la fragmentación del disco. Por ejemplo, vea la figura
siguiente, donde la base de datos está configurada para crecer en 1024 MB cada vez que se
necesita la función de crecimiento automático.

6.7 Directiva de Cluster.

La característica de clústeres de conmutación por error de Windows Server es una plataforma

de alta disponibilidad que supervisa constantemente las conexiones de red y el estado de los
nodos en un clúster. Si un nodo no es accesible a través de la red, se toma la acción de
recuperación para recuperar y poner las aplicaciones y servicios en línea en otro nodo del
clúster. La configuración predeterminada de fábrica está optimizada para errores donde hay
una pérdida completa de un servidor, que se considera un error grave. Estos serían los
escenarios de error irrecuperable como un error de hardware no redundante o del suministro
eléctrico. En estas situaciones, se pierde el servidor y el objetivo es que el clúster de
conmutación por error detecte rápidamente esta pérdida y se recupere rápidamente en otro
servidor del clúster. Para lograr la recuperación rápida de errores grave, la configuración
predeterminada para la supervisión de estado de clúster es bastante exigente. Pero son
totalmente configurables para permitir la flexibilidad para diversos escenarios.
Estos valores predeterminados ofrecen el mejor comportamiento para la mayoría de los
clientes pero, a medida que los clústeres se extienden desde pulgadas hasta posiblemente
millas de distancia, el clúster puede exponerse a componentes de red adicionales y
potencialmente no confiables entre los nodos. Otro factor es que la calidad de los servidores
básicos está aumentando constantemente, junto con una resistencia aumentada mediante
componentes redundantes (por ejemplo, dos fuentes de alimentación, formación de equipos
NIC y E/S de múltiples rutas), el número de errores de hardware no redundante puede ser
bastante poco frecuente. Debido a que los errores graves pueden ser menos frecuentes,
algunos clientes podrían querer ajustar el clúster para los errores transitorios, donde es más
resistente a errores de red breves entre los nodos del clúster. Al aumentar los umbrales de
error predeterminados puede disminuir la sensibilidad a los problemas de red breves que duran
un período de tiempo corto.
Es importante comprender que no hay ninguna respuesta correcta en este caso y que la
configuración optimizada puede variar según sus requisitos empresariales y los contratos de
nivel de servicio.

6.8 Virtualización de SQL Server.

En entornos virtuales, por motivos de rendimiento, se recomienda que almacene la base de

datos operativa y la base de datos de almacenamiento de datos en un almacenamiento
conectado directamente y no en un disco virtual. Use siempre Operations Manager Sizing
Helper para hacer una estimación de IOPS necesaria y comprobar los discos de datos con una
prueba de esfuerzo. Puede aprovechar la herramienta SQLIO para esta tarea.

6.9 Always On, y el Modelo de Recuperación y Backups.

Aunque no es estrictamente una optimización, una consideración importante con respecto al

grupo de disponibilidad de Always On es que, por diseño, esta característica requiere que las
bases de datos se establezcan en el modelo de recuperación "Completo". Esto significa que los
 registros de transacciones nunca se eliminan hasta que se realice una copia de seguridad
completa o solo del registro de transacciones. Por esta razón, la estrategia de copia de
seguridad no es opcional, sino una parte necesaria del diseño de Always On para las bases de
datos. De lo contrario, los discos que contienen los registros de transacciones se llenarán con
el tiempo.

Una estrategia de copia de seguridad debe tener en cuenta los detalles del entorno. En la
siguiente tabla se muestra una programación de copia de seguridad típica.

Tipo de copia de seguridad Programa

Solo del registro de transacciones Cada una hora

Full Semanalmente, los domingos a las 3:00.

7. Optimización de SQL Server Reporting Services.

La instancia de Reporting Services actúa como un proxy para el acceso a datos en la base de
datos de almacenamiento de datos. Genera y muestra los informes basados en plantillas
almacenadas dentro de los módulos de administración.
En segundo plano de Reporting Services, hay una instancia de base de datos de SQL Server
que hospeda las bases de datos de ReportServer y ReportServerTempDB. Se aplican las
recomendaciones generales relacionadas con el ajuste del rendimiento de esta instancia.

8. Seguridad y Permisos de Usuarios.

9. Plan de Administración.

El plan de Administración se estableció con la base de datos DB_MONITOREO debe estar en

todas las instancias de SQL Server, especialmente en las instancias de Producción.

La base de datos contiene ciertos procedimientos para capturar de cada instancia: datos de
auditoria configurados en la instancia, espacios de las bases de datos, tamaño de cada base de
datos cada cierto tiempo, proceso de mantenimiento de estadísticas, proceso de mantenimiento de
índices, usuarios e indicadores de desempeño.

El documento donde se explica el funcionamiento del plan de administración se llama: Base de

Datos DB_MONITOREO.docx el cual se incluye en la entrega formal a Setti.