Buenas Practicas SQL Server

INFORMACIÓN DEL DOCUMENTO Tabla de contenido 1. Requisitos de SQL Server..............................................

Views 104 Downloads 1 File size 157KB

Report DMCA / Copyright

DOWNLOAD FILE

Recommend stories

Citation preview

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:  

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.



2.

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

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.

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 bases de datos de aplicaciones

TCP 1433 *

Entrante servidor de administración y consola web (para Application Advisor y Diagnóstico de aplicaciones)

Servicio SQL Server Browser Conexión de administración dedicada de SQL Server

UDP 1434 TCP 1434

Entrante Entrante

Servidor de administración Servidor de administración

Otros puertos usados por SQL Server - Llamadas a procedimiento remoto de Microsoft (MS RPC)

TCP 135

Entrante

Servidor de administración

Puerto configurado por el administrador

Entrante

Servidor de administración

TCP 80 (predeterminado)/443 (SSL)

Entrante servidor de administración y consola del operador

- Instrumental de administración de Windows (WMI) - Coordinador de transacciones distribuidas de Microsoft (MS DTC) Escucha de grupo de disponibilidad de SQL Server Always On

SQL Server Reporting Services que hospeda el servidor de informes de 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 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.

No se admiten grupos de disponibilidad en los 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.

7.

Tipo de copia de seguridad

Programa

Solo del registro de transacciones

Cada una hora

Full

Semanalmente, los domingos a las 3:00.

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.