Documente Academic
Documente Profesional
Documente Cultură
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:
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.
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.
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
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.
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.
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
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.
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.
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.
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:
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.
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.
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.
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.
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.
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.
9. Plan de Administració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.