SQL Server

31
Ene
2024

Administración de Instancias SQL en Azure

Ayer hablamos en profundidad sobre las instancias administradas de SQL Server en Azure y os prometí dedicar el post de hoy a temas de administración. Vamos a empezar hablando de los modos de licenciamiento y lo que nos ofrece cada uno de ellos y, a continuación, ya entraremos en materia con la administración.

Licenciamiento de instancias administradas en Azure

Como DBAs es probable que recaiga sobre nosotros la elección de la arquitectura SQL y por tanto su licenciamiento. En el caso de las instancias administradas de SQL Server en Azure el modelo de compra se basa en núcleos virtuales. Esto quiere decir que recursos como la RAM dependerán de la cantidad de núcleos de CPU que seleccionemos y no podremos ampliar un recurso sin el resto. Además de los núcleos tenemos otras opciones, por un lado podremos elegir el tipo de hardware y el nivel de servicio. Sé que es un poco lioso así, no os preocupéis que vamos a verlo con detalle.

En base al hardware, tenemos tres planes disponibles: el Gen5, el Premium y el Premium optimizados para memoria. La diferencia entre el Gen5 y el Premium es el tipo de procesador y, por tanto, su velocidad. Además el plan Premium nos da algo más de RAM por cada núcleo que contratemos. El Premium y Premium optimizado para memoria solo se diferencian en que este segundo da aún más RAM por cada núcleo. 

Además, como hemos comentado, cualquiera de estos tres planes se puede contratar en dos niveles de servicio: estándar o crítico para la empresa. El nivel estándar nos proporcionará 16Tb de Azure Blob Storage de alto rendimiento y alta disponibilidad basada en Azure Blob Storage y Azure Service Factory. El nivel crítico para la empresa cambia la opción de almacenamiento por un SSD local extremadamente rápido que reduce la latencia de E/S. El tamaño del SSD variará en función del plan de hardware. Otras ventajas del nivel de servicio crítico es la alta disponibilidad Always On y una réplica de solo lectura adicional. Por último, este nivel, añade OLTP en memoria para usarse en cargas con necesidades de rendimiento muy altas.

La siguiente tabla resume todo lo que hemos comentado, para precios Microsoft ha puesto a nuestra disposición esta calculadora.

Operaciones de administración

Ahora que ya sabemos que opción contratar es momento de crear nuestra primera instancia. Para crear instancias, igual que para cambiar su configuración o eliminarlas, podremos hacerlo desde Azure Portal, usando PowerShell o la CLI (Command Line Interface) de Azure. Al crear una instancia tenemos que elegir el nombre, la ubicación, la versión y la edición de SQL Server, el tamaño del almacenamiento y la configuración del firewall. En cuanto a la configuración, podremos cambiar algunos parámetros como el número de núcleos virtuales (vCores), la cantidad de memoria RAM o el tamaño del almacenamiento. También podemos habilitar o deshabilitar algunas características como el Always On Availability Groups o el Transparent Data Encryption.

Copias de seguridad y restauraciones en instancias en Azure

Antes de empezar con este tema, vamos a hablar de una cosa que todos estáis pensando y que no es para menos. Con la presentación de SQL Server 2022 se nos mostró una funcionalidad llamada “Vínculo para Azure Managed Instance” que, haciendo uso de grupos de disponibilidad distribuidos, nos permitiría mantener sincronizados nuestro entorno On Premise con Azure. Sin embargo, aunque SQL Server 2022 salió al mercado en diciembre de 2022, a día de hoy (Enero de 2024) sigue siendo una versión preliminar que no está disponible para todo el mundo. Sé lo que estáis pensando, es una CHAPUZA que, habiendo pasado más de un año siga sin estar disponible esta característica. No olvidemos que es una de las principales novedades que justificaría la migración a esta versión de SQL Server. Yo tampoco lo entiendo.

Vale, pasemos página y dejemos atrás lo malo (aunque no lo olvidemos) y hablemos de las copias de seguridad en las instancias de Azure. Las copias de seguridad principales, son automáticas y no vamos a poder configurar nada. Las instancias administradas realizan copias de seguridad automáticas cada 5-10 minutos (dependiendo del tamaño de las bases de datos) y las almacenan en un almacenamiento redundante. Podemos restaurar nuestras bases de datos desde estas copias usando Azure Portal o PowerShell. 

Sin embargo, nosotros también podemos realizar copias de seguridad manuales por nuestra cuenta usando T-SQL o PowerShell y almacenarlas en un almacenamiento externo como Azure Blob Storage o un recurso compartido SMB. Estas copias siempre serán Copy-Only para no interferir en la cadena principal de copias automáticas. 

En cuanto a restauración de copias manuales, podremos usar T-SQL o PowerShell para restaurar nuestras copias en la instancia de Azure. Nuestra instancia administrada admitirá copias de otras bases de datos de Azure y de cualquier SQL Server superior a 2008. En el otro sentido, solo podremos restaurar copias de seguridad de Azure en SQL Server 2022.

Actualizaciones de instancias administradas en Azure

Las instancias administradas se actualizan solas con los últimos parches y mejoras de SQL Server sin necesidad de intervención manual. Sin embargo, sí tendremos que elegir entre dos modos de actualización: automático o manual. En el modo automático, las actualizaciones se aplican tan pronto como están disponibles mientras que en modo manual, podemos elegir cuándo aplicarlas. Os recomiendo este último modo para actualizar siempre dentro de una ventana de mantenimiento.

Monitorización de instancias administradas en Azure

Podemos monitorizar y diagnosticar nuestras instancias administradas usando las herramientas habituales que ya conocemos como SQL Server Management Studio o Extended Events. También podemos usar los servicios integrados de Azure como Azure Monitor o Azure SQL Analytics para obtener métricas e insights sobre el rendimiento, la disponibilidad y la salud de nuestras instancias.

Conclusión

Como hemos visto en este artículo y en el anterior, las instancias SQL Server administradas de Azure son una gran solución PAAS en el cloud de Microsoft. Nos ofrecen prácticamente todas las características de un SQL Server local sin necesidad de tenerlo en nuestra infraestructura. Además, Azure se encarga de las copias de seguridad por nosotros y nos garantiza una disponibilidad con un SLA cercano al 100%. Por contra, perdemos flexibilidad a la hora de gestionar ciertos temas de configuración de recursos y nos limita a 16 Tb de espacio en disco. ¿Qué opináis? ¿Trabajáis con esta solución?¿Os planteáis migrar a este servicio? Os leo en comentarios. También podéis dejar vuestro feedback en nuestro Twitter o en nuestro nuevo grupo de LinkedIn.

Publicado por Roberto Carrancio en Cloud, SQL Server, 0 comentarios
30
Ene
2024

Instancias Administradas en Azure (Introducción)

En este artículo vamos a hablar de las instancias administradas de SQL Server en Azure, un servicio que nos permite tener una experiencia casi idéntica a la de un servidor SQL Server tradicional, pero con las ventajas de la nube. Las instancias administradas de SQL Server en Azure son una opción ideal para migrar nuestras bases de datos SQL Server existentes a Azure sin tener que modificar mucho el código ni la configuración. Además, nos ofrecen todas las ventajas de la nube como un alto nivel de rendimiento, seguridad, escalabilidad y disponibilidad.

¿Qué son las instancias administradas de SQL Server en Azure?

Las instancias administradas de SQL Server en Azure son un tipo de servicio PaaS (Platform as a Service) que nos permite crear y administrar instancias de SQL Server en la nube. Estas instancias tienen casi las mismas características y funcionalidades que un servidor SQL Server tradicional. También soportan las mismas versiones y ediciones de SQL Server, desde la 2008 hasta la 2022, y se actualizan automáticamente con los últimos parches y mejoras.

Las instancias administradas de SQL Server en Azure se diferencian de otros servicios de bases de datos SQL en Azure en que nos permiten tener un mayor control sobre la instancia, como el acceso al sistema operativo, la configuración del firewall, la administración de usuarios y roles, la auditoría y el seguimiento, etc. Además, nos permiten usar características avanzadas de SQL Server que no están disponibles en otros servicios, como el Always On Availability Groups, el Transparent Data Encryption, el Change Data Capture, el Service Broker, etc.

¿Cómo se administran?

La administración de las instancias administradas de SQL Server en Azure es muy similar a la de un servidor SQL Server tradicional. Podemos usar las mismas herramientas y métodos que estamos acostumbrados a usar, como el SQL Server Management Studio, PowerShell o T-SQL. También podemos usar los servicios integrados de Azure para facilitar algunas tareas, como el Azure Portal, el Azure Monitor o el Azure Automation. Veremos más sobre este tema en otro post.

Instancias administradas en Azure VS instancias On Premise

Las instancias On Premise son aquellas que se ejecutan en nuestros propios servidores físicos o virtuales, dentro de nuestra infraestructura local. Estas instancias tienen algunas ventajas sobre las instancias administradas en Azure, como un mayor control sobre el hardware, una menor latencia y una mayor personalización. Sin embargo, también tienen algunos inconvenientes, como un mayor coste, una mayor complejidad y una menor flexibilidad.

Las instancias administradas en Azure nos ahorran los costes y las molestias de tener que comprar, instalar y mantener nuestros propios servidores. Además, nos ofrecen una mayor escalabilidad y disponibilidad, ya que podemos aumentar o reducir los recursos según la demanda y contar con la garantía de un SLA (Service Level Agreement) del 99.99%. También nos facilitan la migración y la recuperación de nuestras bases de datos, ya que podemos usar herramientas como el Data Migration Service o el Backup and Restore.

La elección entre las instancias administradas o las instancias on premise dependerá de nuestras necesidades y preferencias. Si queremos tener una solución más económica y flexible, con todas las ventajas de la nube, las instancias administradas son la mejor opción. Si queremos tener una solución más personalizada y con menos dependencia de internet, las instancias on premise pueden ser suficientes.

Instancias administradas en Azure VS Bases de datos de Azure

El servicio de bases de datos SQL en Azure es otro tipo de servicio PaaS que nos permite crear y administrar bases de datos SQL en la nube como ya vimos en el post anterior. Sin embargo, a diferencia de las bases de datos de Azure, las instancias administradas nos ofrecen una instancia completa de SQL Server y no solo una base de datos aislada que se ejecuta en un servidor compartido con otros clientes. Esto implica que tenemos mayor control sobre la base de datos y que podemos usar algunas características de SQL Server propias de la instancia.

El servicio de bases de datos SQL en Azure tiene algunas ventajas sobre las instancias administradas, como un menor coste, una mayor elasticidad y una menor complejidad. Sin embargo, también tiene algunas limitaciones, como una menor compatibilidad con las versiones y ediciones de SQL Server, una menor capacidad para escalar verticalmente y una menor flexibilidad para migrar o restaurar bases de datos.

La elección entre las instancias administradas o el servicio de bases de datos SQL en Azure dependerá de nuestras necesidades y preferencias. Si queremos tener una experiencia similar a la de un servidor SQL Server tradicional, con todas sus características y funcionalidades, las instancias administradas son la mejor opción. Si queremos tener una solución más simple y económica, con solo lo necesario para alojar nuestras bases de datos SQL, el servicio de bases de datos SQL en Azure puede ser suficiente.

Conclusión

Las instancias administradas de SQL Server en Azure son un servicio que nos ofrece una forma fácil y rápida de migrar nuestras bases de datos SQL Server existentes a la nube, sin perder ninguna característica ni funcionalidad. Se trata de un servicio PaaS que nos brinda un alto nivel de rendimiento, seguridad, escalabilidad y disponibilidad, así como un gran control sobre la instancia. Como esto se alargaba ya demasiado, mañana hablamos de temas más técnicos de la administración de este servicio (que seguro que os interesa más), mientras tanto, podéis dejarme vuestros comentarios aquí abajo, en Twitter o por mail.

Publicado por Roberto Carrancio en Cloud, SQL Server, 1 comentario
29
Ene
2024

Azure Database: SQL sin servidor

Seguimos con los artículos sobre SQL en la nube, ya hemos visto por encima todas las posibles soluciones de SQL en Cloud. Hoy quiero compartir con vosotros mi experiencia con Azure Databases, el servicio de bases de datos en la nube de Microsoft. ¿Qué ventajas tiene frente a otras opciones? ¿Cómo podemos migrar nuestras bases de datos SQL Server a Azure? ¿Qué retos y oportunidades nos ofrece este servicio? Estas son algunas de las preguntas que intentaremos responder en este artículo.

¿Qué es Azure Database?

Azure Databases es una plataforma que nos permite crear, administrar y escalar bases de datos en la nube, sin tener que preocuparnos por el hardware, el software o la infraestructura. Podemos elegir entre diferentes tipos de bases de datos, según nuestras necesidades y preferencias: SQL Database, MySQL, PostgreSQL, MariaDB, Cosmos DB, etc. Cada una de estas opciones tiene sus propias características, ventajas y desventajas, que podéis consultar en la documentación oficial de Azure.

Nosotros nos vamos a centrar en SQL Database, que es el servicio que nos permite usar SQL Server en la nube. SQL Server es uno de los sistemas de gestión de bases de datos relacionales más populares y potentes del mercado, y con Azure Databases podemos aprovechar todas sus funcionalidades y beneficios, pero con una mayor flexibilidad, escalabilidad y seguridad.

Una de las funcionalidades más interesantes que nos ofrece SQL Database en Azure es la posibilidad de usar SQL sin servidor (serverless SQL). ¿Qué significa esto? Significa que podemos crear una base de datos que solo consume recursos cuando está activa, y que se pausa automáticamente cuando no hay actividad. De esta forma, podemos ahorrar costes y optimizar el uso de los recursos. Además, podemos escalar la base de datos según la demanda, sin tener que especificar un tamaño fijo.

¿Qué beneficios tiene usar SQL sin servidor?

Algunos de los más destacados son:

  • No tenemos que comprar ni mantener servidores físicos ni licencias de software. Solo pagamos por lo que usamos, según el tiempo y el rendimiento que consuma nuestra base de datos.
  • Podemos crear y eliminar bases de datos rápidamente, sin tener que esperar a que se aprovisionen o desaprovisionen los recursos.
  • Podemos adaptar nuestra base de datos a las fluctuaciones del tráfico o la actividad, sin tener que hacer cambios en el código ni en la configuración. Azure se encarga de ajustar los recursos automáticamente según la demanda.
  • Podemos acceder a nuestra base de datos desde cualquier lugar y dispositivo, usando las herramientas y lenguajes que prefiramos. Azure nos ofrece una alta disponibilidad y redundancia, garantizando un tiempo de actividad del 99,99%.
  • Podemos proteger nuestra base de datos con las mejores prácticas de seguridad, como el cifrado de datos en reposo y en tránsito, el control de acceso basado en roles, la auditoría y el monitoreo. Además, Azure nos ofrece copias de seguridad automáticas y opciones de recuperación ante desastres.
  • Podemos integrar nuestra base de datos con otros servicios de como Azure Synapse Analytics, Azure Machine Learning o Azure Data Factory, para obtener más valor e insights de nuestros datos.

¿Cómo podemos crear una base de datos SQL sin servidor en Azure?

El proceso es muy sencillo y podéis seguir los pasos que se indican aquí. Básicamente, tenemos que:

  1. Acceder al portal de Azure e ir al servicio SQL Database.
  2. Hacer clic en Crear recurso y seleccionar Base de datos única.
  3. Rellenar los campos del formulario con los datos de nuestra base de datos: nombre, grupo de recursos, servidor, etc.
  4. En el apartado Tamaño + rendimiento, elegir la opción vCore como modelo de compra y seleccionar la casilla Habilitar SQL sin servidor.
  5. Configurar los límites mínimos y máximos de vCore y memoria para nuestra base de datos.
  6. Revisar y crear la base de datos.

Una vez creada la base de datos, podemos conectarnos a ella usando las herramientas y lenguajes que prefiramos: SSMS, Azure Data Studio, Visual Studio Code, PowerShell, etc. También podemos usar el portal de Azure para administrar y monitorear nuestra base de datos.

¿Qué necesitamos para implementar una base de datos de Azure?

Como todo cambio tecnológico, usar SQL sin servidor en Azure implica algunos desafíos y adaptaciones, pero también nos abre un mundo de posibilidades. Algunos aspectos a tener en cuenta son:

  • Debemos elegir bien el nivel de rendimiento y los límites de recursos que queremos para nuestra base de datos. Azure nos ofrece una calculadora de precios que nos ayuda a estimar el coste de nuestra base de datos según el tiempo y el rendimiento que consuma.
  • Debemos tener en cuenta que nuestra base de datos se pausará automáticamente cuando no haya actividad, lo que puede afectar al tiempo de respuesta de la primera consulta después de la reanudación. Podemos configurar el tiempo de espera antes de la pausa, que por defecto es de una hora, según nuestras preferencias.
  • Debemos aprovechar las nuevas funcionalidades y características que nos ofrece SQL sin servidor en Azure. Por ejemplo, podemos usar la inteligencia artificial para mejorar la calidad y el análisis de nuestros datos, usando servicios como Cognitive Services o Azure Machine Learning. También podemos usar la computación distribuida para procesar grandes volúmenes de datos, usando servicios como Azure Synapse Analytics o Azure Databricks.

¿Cómo podemos migrar nuestra base de datos SQL Server a Azure?

Hay varias opciones disponibles, según el tamaño y la complejidad de nuestra base de datos. Algunas de las más comunes son:

  • Usar la herramienta Data Migration Assistant (DMA) que ya hemos visto en profundidad en este post.
  • Utilizar el servicio Azure Database Migration Service (DMS), que nos permite migrar nuestra base de datos online u offline, con una mínima interrupción del servicio y una alta fiabilidad.
  • Usar el método bacpac, que consiste en exportar nuestra base de datos a un archivo .bacpac y luego importarlo a Azure mediante el portal o PowerShell.
  • Utilizar el método log shipping, que consiste en copiar los archivos .mdf y .ldf de nuestra base de datos a un blob storage en Azure y luego restaurarlos mediante T-SQL.

Conclusión

SQL sin servidor en Azure es una excelente opción para usar SQL Server en la nube, con todas las ventajas que ello implica. Nosotros hemos creado algunas bases de datos SQL sin servidor en Azure y estamos muy satisfechos con los resultados. Os animamos a que lo probéis y nos contéis vuestra experiencia. Si tenéis alguna duda o comentario, podéis escribirnos por mail o seguirnos en nuestra cuenta de Twitter. ¡Hasta la próxima!

Publicado por Roberto Carrancio en Cloud, SQL Server, 1 comentario
26
Ene
2024

Data Migration Assistant: Migrar de SQL Server a Azure SQL

En el pasado post vimos las distintas soluciones de SQL en la nube. En este post vamos a hablar de la herramienta Data Migration Assistant (o DMA), una aplicación de Microsoft que nos va a permitir migrar bases de datos SQL de nuestros servidores On Premise a la nube de Azure de forma fácil y rápida. Esta herramienta es ideal para los profesionales que quieren aprovechar las ventajas de la nube, como la escalabilidad, la seguridad y el ahorro de costes, sin perder el control y el rendimiento de sus datos.

Que es Data Migration Assistant

Data Migration Assistant es una solución integrada que nos ofrece Microsoft para facilitar el proceso de migración de bases de datos SQL a Azure. Con esta herramienta, además, podemos realizar las siguientes tareas:

  • Analizar el estado y la compatibilidad de nuestras bases de datos SQL con Azure.
  • Seleccionar el servicio de Azure más adecuado para alojar nuestras bases de datos, ya sea Azure SQL Database, Azure SQL Managed Instance o Azure SQL Server en una máquina virtual.
  • Realizar la migración de los datos, los esquemas, los objetos y las configuraciones de nuestras bases de datos SQL a Azure.
  • Validar y monitorizar el resultado de la migración y resolver posibles problemas.

¿Cómo usar Data Migration Assistant?

Para usar Data Migration Assistant necesitamos tenerlo instalado en nuestro equipo local, no os preocupéis porque es una aplicación gratuita que nos permite realizar el análisis y la evaluación de nuestras bases de datos SQL. También necesitamos tener una cuenta de Azure con una suscripción activa.

El proceso de migración se realiza en cuatro pasos:

  1. Crear un proyecto de migración en el DMA, indicando el origen y el destino de los datos, el tipo de migración (esquema, datos o ambos) y el alcance del proyecto (una o varias bases de datos).
  2. Ejecutar una evaluación de las bases de datos seleccionadas, que nos mostrará un informe con los posibles problemas de compatibilidad, las recomendaciones y las acciones correctivas que debemos realizar antes de la migración.
  3. Crear o seleccionar el servicio de Azure donde queremos alojar nuestras bases de datos, configurando los parámetros necesarios como el tamaño, la ubicación, la red y la seguridad.
  4. Ejecutar la migración propiamente dicha, que se realizará en modo online u offline dependiendo del servicio de destino elegido. Durante la migración podremos ver el progreso y el estado de cada base de datos.

Al finalizar la migración podremos acceder a nuestras bases de datos SQL en Azure desde cualquier dispositivo y aplicación, con las mismas funcionalidades y herramientas que teníamos en On Premise, pero con las ventajas añadidas de la nube.

Otros usos de Data Migration Assistant

Además de para migrar hacia Azure, DMA nos permite realizar migraciones entre otros entornos incluidos de On Premise a On Premise, AWS a On Premise, incluso a servidores SQL en servidores Linux. DMA acepta como origen todas las versiones de SQL Server On Premise desde SQL 2005 hasta SQL 2022 así como AWS RDS. Como destino podremos seleccionar cualquier SQL On Premise desde SQL 2012 hasta SQL 2022 o los servicios de Azure ya mencionados.

Por si esto fuese poco, no solo migrará nuestras bases de datos sino también objetos como inicios de sesión, roles de servidor e, incluso, evaluará la viabilidad de la migración de los paquetes SSIS.

Alternativas

Si no queremos usar Data Migration Assistant para realizar la migración, existen otras alternativas como:

  • Usar el portal de Azure o PowerShell para crear y configurar manualmente los servicios de destino y copiar los datos mediante herramientas como SQL Server Management Studio (SSMS), Azure Data Studio o bcp.
  • Usar Azure Database Migration Service (DMS), que es un servicio gestionado que nos permite realizar migraciones online o offline con un mínimo tiempo de inactividad. DMS soporta más tipos de origen y destino que DMA, como Oracle, MySQL o PostgreSQL.
  • Usar otras herramientas o servicios externos que ofrezcan soluciones específicas para cada caso, como Apex, Flyway, Redgate o Attunity.

Conclusión

Data Migration Assistant es una herramienta muy útil cuando queremos llevar a cabo una migración de SQL Server a la nube o a un entorno local sin complicaciones ni riesgos. Con esta herramienta podemos realizar una migración rápida, segura y eficiente, aprovechando al máximo los recursos y servicios que nos ofrece Azure. Si os ha quedado cualquier duda o queréis contarme vuestra opinión os leo en los comentarios, en Twitter o en mi mail..

Publicado por Roberto Carrancio en Cloud, SQL Server, 2 comentarios
25
Ene
2024
SQL Server en la nube

SQL Server en la nube

Hoy vamos a hablar de las soluciones SQL en la nube que ofrecen tanto Azure de Microsoft como AWS de Amazon. Entre otras cosas vamos a ver: ¿Qué ventajas tiene alojar una base de datos en la nube? ¿Qué opciones tenemos para elegir la plataforma más adecuada para nuestras necesidades? ¿Qué diferencias hay entre una base de datos solo en Azure, una instancia gestionada en Azure o AWS RDS, y una máquina virtual con una instancia instalada en Azure o en AWS? 

¿Por qué debería irme a la nube?

Lo primero que hay que tener en cuenta es que la nube nos ofrece una serie de beneficios que no podemos obtener con una base de datos local. Algunos de estos beneficios son:

  • Escalabilidad: podemos aumentar o disminuir los recursos asignados a nuestra base de datos según la demanda, sin tener que invertir en hardware adicional o realizar complejas migraciones.
  • Disponibilidad: la nube nos garantiza un alto nivel de disponibilidad y redundancia, lo que significa que nuestra base de datos estará siempre accesible y protegida ante posibles fallos o desastres.
  • Seguridad: la nube cuenta con medidas de seguridad avanzadas que protegen nuestra base de datos de ataques externos o internos, así como de pérdidas o fugas de datos.
  • Coste: la nube nos permite pagar sólo por los recursos que utilizamos, lo que, teóricamente, supone un ahorro frente al coste fijo de mantener una infraestructura propia.

Opciones SQL en la nube

Ahora bien, ¿qué plataforma elegir para alojar nuestra base de datos SQL en la nube? Tanto Azure como AWS son dos gigantes del sector que ofrecen soluciones robustas y flexibles para diferentes escenarios. Veamos algunas de las opciones que tenemos en cada una de ellas.

Primera opción: Base de datos en la nube:

La primera opción sería alojar nuestra base de datos solo en Azure, es decir, utilizar el servicio Azure SQL Database. Podríamos decir que esta es la opción de entrada a la nube de Microsoft. Este servicio nos permite crear y gestionar bases de datos relacionales en la nube, sin tener que preocuparnos por el mantenimiento o la administración del servidor. Azure SQL Database se encarga de todo: desde el aprovisionamiento hasta el backup, pasando por el parcheo, el monitoreo o el balanceo de carga. Además, Azure SQL Database nos ofrece compatibilidad con el lenguaje T-SQL y con las herramientas y aplicaciones habituales de SQL Server, lo que facilita la migración desde una base de datos local. Otra ventaja es que Azure SQL Database se integra con otros servicios de Azure, como Azure Active Directory, Azure Synapse Analytics o Azure Machine Learning.

Segunda opción: Instancia SQL en la nube:

La siguiente opción es utilizar una instancia gestionada en Azure, es decir, el servicio Azure SQL Managed Instance. Este servicio es similar al anterior, pero nos ofrece un mayor grado de control y personalización sobre nuestra base de datos. Con Azure SQL Managed Instance podemos configurar aspectos como el tamaño del almacenamiento, el número de núcleos, el nivel de aislamiento o el modelo de recuperación. Además, Azure SQL Managed Instance nos permite acceder a características propias de SQL Server, como el servicio de agente, los trabajos programados, las réplicas secundarias o el cifrado transparente de datos. Esta opción es ideal para aquellos casos en los que necesitamos una mayor compatibilidad con SQL Server o una mayor flexibilidad para adaptar nuestra base de datos a nuestros requisitos.

Si queremos usar una solución de Amazon nuestra opción será utilizar RDS, es decir, el servicio Amazon Relational Database Service. Este servicio nos permite crear y gestionar bases de datos relacionales en la nube utilizando diferentes motores, entre ellos SQL Server. Al igual que los servicios anteriores, RDS se encarga del aprovisionamiento, el backup, el parcheo y el monitoreo de nuestra base de datos. Además, RDS nos ofrece características como la replicación múltiple, el escalado automático, la restauración puntual o la migración de datos. RDS se integra con otros servicios de AWS, como Amazon S3, Amazon VPC o Amazon CloudFormation.

Tercera opción: Servidor en la nube:

Para terminar, otra opción es utilizar una máquina virtual con una instancia instalada en Azure o en AWS. Esta opción consiste en crear una máquina virtual en la nube y luego instalar y configurar manualmente una instancia de SQL Server en ella. Esta opción nos da el máximo control sobre nuestra base de datos, ya que podemos elegir el sistema operativo, el hardware y las características que queremos utilizar. Sin embargo, esta opción también implica un mayor esfuerzo y responsabilidad por nuestra parte, ya que tendremos que ocuparnos del mantenimiento y la administración tanto del servidor como de la base de datos. Esta opción es recomendable para aquellos casos en los que tenemos requisitos muy específicos o complejos que no podemos cubrir con las opciones anteriores.

¿Qué opción elegir?

Como hemos visto, tanto Azure como AWS nos ofrecen diferentes formas de alojar una base de datos SQL en la nube, cada una con sus ventajas e inconvenientes. La elección dependerá de factores como el presupuesto, el rendimiento, la compatibilidad, la seguridad o la facilidad de uso. Lo importante es analizar bien nuestras necesidades y comparar las distintas opciones para encontrar la que mejor se adapte a nuestro proyecto.

Conclusión

Espero que este artículo te haya resultado útil e interesante. Próximamente profundizaremos más en estas soluciones en la nube y herramientas específicas. 

Soluciones SQL CLOUD

¿Vosotros qué opináis? ¿Os convencen las soluciones en la nube? Os leo en los comentarios y en Twitter.

Publicado por Roberto Carrancio en Cloud, SQL Server, 4 comentarios
24
Ene
2024

Optimizando SQL Server para BizTalk

Durante los anteriores post hemos comentado las recomendaciones de instalación de SQL para SharePoint y sus configuraciones recomendadas, como ha tenido muy buena acogida vamos a continuar con esta línea esta vez hablando de las buenas prácticas de SQL Server para BizTalk. 

Existen varios factores que tenemos que tener en cuenta en nuestro SQL Server para BizTalk. En este artículo vamos a intentar ver los más importantes no solo para configurar nuestro SQL sino para mantenerlo y solucionar los problemas que nos puedan surgir.

¿Qué es BizTalk?

Empecemos por el principio, BizTalk es un producto de Microsoft que facilita la comunicación entre sistemas heterogéneos, tanto dentro como fuera de la organización. BizTalk permite crear flujos de trabajo (orquestaciones) que definen la lógica y las reglas de negocio para procesar los mensajes que se intercambian entre los sistemas. Además, también ofrece herramientas para transformar, enrutar, monitorizar y auditar los mensajes, así como para gestionar las excepciones y errores que puedan ocurrir.

BizTalk se basa en una arquitectura distribuida que consta de varios componentes, entre los que se encuentra SQL Server. SQL Server es el encargado de almacenar la información relativa a las configuraciones, las instancias, las suscripciones, el seguimiento y el archivado de los mensajes. Por tanto, el rendimiento y la disponibilidad de SQL Server son fundamentales para el correcto funcionamiento de BizTalk.

Bases de datos de BizTalk

BizTalk usa varias bases de datos y es importante que las conozcamos pues no todas van a requerir las mismas medidas por nuestra parte. Las principales bases de datos que debemos conocer son: BizTalkMgmtDb (base de datos de administración), BizTalkMsgBoxDb (base de datos del buzón), BizTalkDTADb (base de datos del seguimiento), SSO (base de datos del servicio de configuración) y BAM (base de datos del análisis de negocio).

Usuarios de BizTalk

Además de las bases de datos BizTalk creará una serie de inicios de sesión y roles en nuestro SQL Server. Podemos verlo en la siguiente tabla que proporciona Microsoft (haz click sobre la imagen para ampliar).

Usuarios-SQL-Biztalk

Configuraciones de SQL Server ideales para BizTalk

Con estos conocimientos previos en mente ya podemos entrar en materia sobre la configuración de SQL Server específica para BizTalk. Vais a ver que algunas son similares a las que vimos para SharePoint. 

Configuraciones de SQL Server

Es importante que establezcamos el nivel de paralelismo a 1, ya que BizTalk genera muchas (muchísimas) consultas aunque muy ligeras. Con esto nos aseguraremos de poder dar salida a las máximas consultas posibles de manera simultánea.

En cuanto al Fill Factor, la documentación oficial no hace mención a un valor concreto sin embargo sí que nos habla de que la mayoría de los índices son clustered y con identificadores únicos basados en GUID por lo que no es recomendable poner un Fill Factor del 100%. Mi consejo es dejar el parámetro por defecto ya que no se especifica otra cosa. Más adelante volveremos al tema de los índices porque va a ser un dolor de cabeza.

Configuración de TempDB

Aunque este es un consejo general para todos los SQL Server, en el caso de BizTalk tiene mucha importancia porque ejecuta cantidades impensables de transacciones. Dividiremos nuestra base de datos en tantos ficheros como núcleos tenga nuestra CPU (hasta un máximo de 8) a fin de que varios hilos puedan acceder al recurso sin bloqueos de páginas. Todos los ficheros tendrán el mismo tamaño inicial y si usamos un SQL inferior a 2016 habilitaremos la traza  -T1117 en el arranque para que todos los ficheros crezcan simultáneamente. Sin embargo, debemos anticipar el tamaño de la TempDB y dimensionarla previamente para evitar el extra de tiempo del crecimiento de los archivos.

Tamaños de las bases de datos de BizTalk

Al igual que con la TempDB es importante que establezcamos un tamaño inicial y un crecimiento a los ficheros de las bases de datos de la aplicación para optimizar el rendimiento. En entornos pequeños y medianos podemos usar el siguiente script:

EXEC dbo.sp_helpdb BizTalkMsgBoxDb ALTER DATABASE BizTalkMsgBoxDb MODIFY FILE (NAME = BizTalkMsgBoxDb , FILENAME = '\BizTalkMsgBoxDb.mdf' , SIZE = 2GB , FILEGROWTH = 100MB) ALTER DATABASE BizTalkMsgBoxDb ADD FILE (NAME = BizTalkMsgBoxDb_2 , FILENAME = '\BizTalkMsgBoxDb_2.ndf' , SIZE = 2GB , FILEGROWTH = 100MB) ALTER DATABASE BizTalkMsgBoxDb ADD FILE (NAME = BizTalkMsgBoxDb_3 , FILENAME = '\BizTalkMsgBoxDb_3.ndf' , SIZE = 2GB , FILEGROWTH = 100MB) ALTER DATABASE BizTalkMsgBoxDb ADD FILE (NAME = BizTalkMsgBoxDb_4 , FILENAME = '\BizTalkMsgBoxDb_4.ndf' , SIZE = 2GB , FILEGROWTH = 100MB) ALTER DATABASE BizTalkMsgBoxDb ADD FILE (NAME = BizTalkMsgBoxDb_5 , FILENAME = '\BizTalkMsgBoxDb_5.ndf' , SIZE = 2GB , FILEGROWTH = 100MB) ALTER DATABASE BizTalkMsgBoxDb ADD FILE (NAME = BizTalkMsgBoxDb_6 , FILENAME = '\BizTalkMsgBoxDb_6.ndf' , SIZE = 2GB , FILEGROWTH = 100MB) ALTER DATABASE BizTalkMsgBoxDb ADD FILE (NAME = BizTalkMsgBoxDb_7 , FILENAME = '\BizTalkMsgBoxDb_7.ndf' , SIZE = 2GB , FILEGROWTH = 100MB) ALTER DATABASE BizTalkMsgBoxDb ADD FILE (NAME = BizTalkMsgBoxDb_8 , FILENAME = '\BizTalkMsgBoxDb_8.ndf' , SIZE = 2GB , FILEGROWTH = 100MB) GO ALTER DATABASE BizTalkMsgBoxDb MODIFY FILE (NAME = BizTalkMsgBoxDb_log , FILENAME = '\BizTalkMsgBoxDb_log.LDF', SIZE = 20GB , FILEGROWTH = 100MB) GO 

Utilizaremos estos parámetros para entornos standalone y pequeños. En un entorno BizTalk de alto rendimiento, deberemos considerar dividir la BizTalkMsgBoxDb en 8 archivos de datos, cada uno con un tamaño de archivo de 2 GB con 100 MB de crecimiento y un archivo de registro de 20 GB con 100 MB de crecimiento. Debido a que las bases de datos BizTalk MessageBox son las más activas, colocaremos los archivos de datos y los archivos de log de transacciones en unidades dedicadas para reducir la probabilidad de problemas de E/S de disco, como vamos a ver ahora.

Configuración de discos duros de SQL Server para BizTalk

Entramos, sin duda, en el apartado más importante para el futuro rendimiento de nuestras aplicaciones BizTalk, de esto va a depender que nuestra aplicación siga funcionando como al principio cuando empiece a tener un tamaño considerable. Por eso es el apartado en el que más nos vamos a extender hoy.

Por defecto, BizTalk coloca la base de datos MessageBox en un único archivo en el grupo de archivos predeterminado. Y por defecto, los datos y logs de transacciones para todas las bases de datos también se colocan en la misma unidad y ruta. Esto se hace para poder funcionar en sistemas con un único disco. Sin embargo, esta configuración de un único archivo, grupo de archivos y disco no es óptima en un entorno de producción. Para un rendimiento óptimo, los archivos de datos y los archivos de log deben colocarse en discos separados.

Otra cosa que debemos tener en cuenta, especialmente para entornos de alto volumen, y de nuevo, porque las bases de datos MessageBox y Tracking son las más activas, es colocar los archivos de datos y los logs de transacciones de estas dos bases de datos en unidades dedicadas para reducir la probabilidad de problemas de E/S de disco.

Por tanto para un rendimiento óptimo nuestro SQL Server deberá tener por lo menos 7 discos duros de datos:

  1. Archivo(s) de datos MessageBox
  2. Archivo(s) de log de transacciones de MessageBox
  3. Archivo(s) de datos de BizTalk Tracking (DTA)
  4. Archivo(s) de log de transacciones de BizTalk Tracking (DTA)
  5. Otros archivos de datos de bases de datos BizTalk
  6. Otros archivos de registro de transacciones de bases de datos BizTalk
  7. TEMPDB

Buscando la perfección en el reparto de discos

Esta técnica descrita anteriormente será familiar para cualquiera que haya creado una instalación grande y multiservidor de BizTalk Server. Además, es preferible que la base de datos de seguimiento (DTA) se sitúe en un servidor separado (o clúster en un entorno de alta disponibilidad) del buzón de mensajes.
Otra de las mejores optimizaciones de rendimiento que podemos hacer es repartir las tablas de las bases de datos de BizTalk entre varios grupos de archivos. Cada grupo de archivos añade un hilo de E/S que, junto con el archivo de datos en un LUN separado, mejorará enormemente el rendimiento (con ganancias del 100-1000%, dependiendo de las características de carga del sistema). No sólo moveremos los datos de la tabla a grupos de archivos separados, sino también los datos LOB y los índices no agrupados. Esto maximiza el paralelismo entre consultas y otras operaciones de base de datos. Haremos esto si nuestra base de datos MessageBox es cercana o mayor a 15 GB. 

En entornos pequeños o medianos sin una gran cantidad de mensajes, no es necesario tener tanta separación en discos. Sin embargo, es muy recomendable que al menos tengamos unidades dedicadas para los archivos de datos y de logs (para permitir que la actividad de E/S se produzca al mismo tiempo para los archivos de datos y de log) y una unidad dedicada para TEMPDB.

Índices y estadísticas en las bases de datos de BizTalk

BizTalk hace su propia gestión de los índices y estadísticas de las bases de datos por lo que tendremos que asegurarnos de que todas las bases de datos de la aplicación tengan tanto la creación como la actualización automática de estadísticas deshabilitadas.

El tema de los índices es más delicado, ya que un mal mantenimiento nos llevará a un escenario insostenible de continuos bloqueos que harán perder la paciencia a los usuarios. Para complicarnos aún más las cosas BizTalk no admite un mantenimiento estándar de índices, es decir no podremos programar nuestros habituales planes de mantenimiento nativos o de Ola Hallengren, o bloquearemos por completo la aplicación.

El único método admitido para mantenimiento de índices en la base de datos BizTalkMsgBoxDb es ejecutar el procedimiento almacenado bts_RebuildIndexes. En BizTalk Server 2006 y versiones posteriores, tenemos también el procedimiento almacenado dtasp_RebuildIndexes para en la base de datos BizTalkDTADb. Por si te parece poco, estos procedimientos solo se pueden ejecutar cuando la aplicación no tiene carga, es decir cuando no está procesando mensajes por lo que es vital acordar con el administrador de la aplicación una ventana de mantenimiento para ejecutarlo. Para poder ejecutar el mantenimiento de índices todas las instancias de BizTalk y el Agente de SQL deben estar detenidos.

Niveles de aislamiento

El valor predeterminado de Transaction Isolation Level es Serializable para el adaptador de BizTalk WCF-SQL tanto para las operaciones entrantes y salientes. Esto provoca gran cantidad de bloqueos, que aunque no deberían ser un problema en entornos pequeños y con poca carga de trabajo puede que nos de problemas en cuanto el volumen de peticiones se incremente. Por suerte el administrador de BizTalk podrá cambiar esta configuración. Revisa nuestro articulo de niveles de aislamiento para entender mejor este tema.

Agente de SQL Server

Por último, pero no menos importante, como se suele decir, tenemos que prestar atención a los jobs de SQL Server que genera BizTalk. Dependiendo de la versión de BizTalk se generarán 12 o 13 jobs, la mayoría realizan procesos internos de la aplicación que, como DBAs, no hace falta conocer. Sin embargo es muy importante que si atendamos a dos de ellos que se llaman «Backup BizTalk Server» y  «DTA Purge and Archive». Estos dos jobs son críticos y por defecto nos vienen programados por lo que tendremos que hacerlo nosotros. El primero de ellos, como habréis adivinado por el nombre, se encarga de las copias de seguridad de las bases de datos siguiendo las buenas prácticas de Microsoft para ello. El segundo, es el encargado de purgar y archivar la información de la base de datos de seguimiento y, eso es lo principal para no tener degradaciones del rendimiento.

Conclusión

En este artículo he compartido con vosotros algunas buenas prácticas de configuración de SQL Server para BizTalk, que os pueden ayudar a mejorar el rendimiento, la escalabilidad y la seguridad de vuestra plataforma de integración. Espero que os hayan resultado útiles y que las pongáis en práctica. Si tenéis alguna duda o comentario, podéis dejarlo abajo, en mi Twitter o por mail. 

Optimiza tu SQL Server para BizTalk

PD: Si esto os ha parecido poco podéis ampliar toda esta información el la guía de documentación de Microsoft aquí.

Publicado por Roberto Carrancio en Rendimiento, SQL Server, 0 comentarios
23
Ene
2024
Configurando SQL Server para SharePoint

Configurando SQL Server para SharePoint

En el post de hoy vamos a continuar configurando nuestro SQL Server para alojar bases de datos de SharePoint. Si ayer vimos lo necesario para diseñar correctamente la infraestructura y las peculiaridades de una instalación con este fin hoy vamos a continuar con las configuraciones específicas que tendremos que implementar para lograr el mejor rendimiento posible.

En el menú del día tenemos de plato principal las buenas prácticas de configuración y terminaremos con las particularidades del mantenimiento de este tipo de bases de datos. 

Configuraciones específicas de SQL Server para SharePoint

Como hemos dicho, SharePoint necesita de una serie de configuraciones particulares en nuestros servidores de SQL Server. Si bien no estamos hablando de funcionalidades que existen en exclusiva para esta herramienta, la combinación de estas configuraciones nos permitirá sacar todo el partido posible de nuestras bases de datos.

Configuraciones de disco duro

Dedicamos gran parte del pasado post a este apartado, no es para menos, como os dije SharePoint es una herramienta que hace un uso intensivo de este recurso. Sobre todo lo que ya hablamos quiero añadir que una vez instalado SQL Server, y si tenemos varios tipos distintos de discos para almacenar nuestras bases de datos, usaremos nuestros discos más rápidos para la TempDB y los registros de transacciones de las bases de datos. Seguido por los archivos de las bases de datos de búsqueda.
Para terminar almacenaremos los archivos de datos de las bases de datos de contenido y por último las bases de datos de configuración. A poder ser usaremos discos optimizados para escrituras en la base de datos TempDB y en los logs de transacciones y optimizados para lectura en las bases de datos de búsqueda y contenido. Si nuestro SharePoint está más enfocado a la lectura que a las escrituras priorizaremos los archivos de datos sobre los logs de transacciones.
Recuerda también configurar el tamaño de bytes per cluster a 64kb tal como vimos en las buenas prácticas generales para SQL Server.

Configuración de memoria RAM

A nivel sistema operativo, configuraremos la paginación manualmente con un tamaño fijo de 1,5 veces el tamaño de la memoria RAM que tenga nuestro servidor. Este archivo de paginación estará en un disco dedicado lo más rápido posible.  En SQL Server configuraremos la memoria mínima y la máxima de SQL Server siempre dejando un mínimo de 3 o 4 Gb libres para que el sistema operativo pueda funcionar. Para estos servidores, siempre que tengamos un servidor SQL dedicado configuraremos el mismo valor de memoria mínimo y máximo. 

Para entender esto es necesario saber cómo funciona la asignación de memoria en SQL Server, veámoslo rápidamente. SQL Server gestiona los recursos de nuestra máquina a través de su propio subsistema operativo dedicado. Este SQL SO, además de gestionar las colas de CPU gestiona la memoria RAM. Cuando arrancamos SQL Server irá “cogiendo” memoria a medida que la necesite (hasta el valor máximo que hayamos asignado) y cuando deje de necesitarla se la quedará reservada. Si el sistema operativo tiene falta de memoria SQL “devolverá” la que no esté usando (hasta quedarse en el valor mínimo que hayamos definido). Esto quiere decir que nuestro SQL puede consumir menos RAM del mínimo que le hayamos asignado si hasta ese momento no ha necesitado de esa memoria.

Una vez que ya tenemos claro cómo funciona la gestión de memoria de SQL Server podemos entender lo que necesitamos para nuestro SQL Server para SharePoint. Asignaremos un valor mínimo igual más máximo y será el total de la RAM disponible menos los 3 o 4 Gb que necesita el sistema operativo y lo que estimemos que necesitan otras aplicaciones imprescindibles como las de copia de seguridad.

Otras configuraciones de SQL Server

Para continuar con las configuraciones de nuestra instancia de SQL Server las buenas prácticas hablan de activar la opción de comprimir backups. Como en este blog nos gusta profundizar en los temas vamos a entrar en detalle en este punto. Comprimir backup tiene un mayor consumo de recursos y un peor rendimiento a la hora de hacer y restaurar las copias de seguridad. Hablamos obviamente de recursos de CPU y RAM. El problema viene con el resto de recursos, disco y red. Como hablamos de bases de datos pesadas, el extra de coste en CPU y RAM se ve compensado por la reducción de disco y de red por lo que en este caso es una buena práctica recomendada.

Otra de las recomendaciones que nos da Microsoft para los servidores SQL Server para Sharepoint es configurar el Fill Factor al 80%. No vamos a entrar en detalle sobre esto ya que ya hemos hablado de ello en otro post.

Cerramos el apartado sobre las configuraciones hablando de la configuración de CPU, en este caso estableceremos el nivel de paralelismo a 1. El nivel de paralelismo indica cuántos núcleos de CPU usarán nuestras consultas, un valor elevado es ideal para servidores con pocas consultas pero pesadas mientras que en servidores con multitud de consultas un valor bajo nos ayudará a tener más consultas ejecutándose simultáneamente. Dado el alto volumen de transacciones simultáneas que va a generar SharePoint en nuestro SQL Server un valor distinto de 1 perjudicará enormemente el rendimiento. 

Configuraciones de bases de datos para SharePoint

Para nuestras bases de datos debemos asegurarnos de que no esté habilitada la opción AutoShink y que no haya ningún trabajo programado que reduzca los ficheros de bases de datos. Aunque esta es una recomendación para la mayoría de bases de datos, en el caso de SharePoint se suele decir que los shrink quedan reservados a ocasiones especiales cuando se haya borrado más del 50% de los datos por parte de un administrador del sitio y tengamos claro que ese espacio no se va a volver a necesitar.

De la misma manera deshabilitaremos la creación y la actualización automática de estadísticas ya que SharePoint se encargará automáticamente de su creación. El tema de las actualizaciones lo vamos a ver luego, cuando hablemos del mantenimiento.

Configuraciones de los ficheros de base de datos de SharePoint

Continuamos con los ficheros de base de datos y como no podía ser de otra manera también tienen configuraciones específicas. En este caso relativas a la distribución y crecimiento.  En una situación ideal, los administradores de SharePoint serán capaces de proporcionarnos el crecimiento esperado de las bases de datos en un año, en estos casos dimensionamos los ficheros en ese tamaño estimado más un 20% de margen. Sin embargo, la realidad es distinta, normalmente no sabremos la tasa de crecimiento anual. En estos casos dimensionamos nuestros ficheros al máximo (o cerca del máximo) del tamaño que hayamos estimado que vayan a crecer  en total(recuerda que en el anterior post explicamos la fórmula para calcular el crecimiento de las bases de datos).
Por lo general, Microsoft no recomienda bases de datos de más de 200Gb para SharePoint, en caso de necesitar más espacio deberá estar dividido en colecciones en distintas bases de datos. SharePoint tiene su propia herramienta para poder mover colecciones entre bases de datos. Tener los ficheros dimensionados a su máximo tamaño nos ahorrará el tiempo que dedica el motor de base de datos a ampliar el tamaño de estos cuando no tiene sitio para alojar información nueva y optimiza las escrituras en SharePoint. 

Crecimiento de los ficheros de base de datos de SharePoint

Sin embargo, aunque tengamos los ficheros dimensionados es importante configurarlos con crecimiento automático para que, en caso de ser necesario, puedan crecer. Configuraremos un crecimiento automático elevado, para evitar que cada transacción nueva tenga que dedicar tiempo a esta tarea. No tengáis miedo a los crecimientos en bloques de varios Gb, recordad que nuestros SharePoint van a almacenar documentos de varios cientos de Mb en ocasiones. Estableceremos crecimientos de 512 Mb para las bases de datos pequeñas y de 5 Gb para las bases de datos de más de 50 Gb. Usar porcentajes de crecimiento no es una práctica recomendada.

Por último, para los logs de transacciones, configuraremos un tamaño de un 25% o 30% del tamaño total de los ficheros de datos.

Distribución de los ficheros de base de datos de SharePoint

Configuraremos nuestras bases de datos de contenido con varios ficheros, a poder ser en varios discos (y varios LUNs) para ganar rendimiento de E/S. En estos casos usaremos la misma regla que usamos normalmente para la TempDB, crearemos un fichero por cada núcleo de nuestro procesador con un máximo de 8 ficheros. Es importante que todos los ficheros tengan el mismo tamaño inicial, pues crecerán a la vez y esto mejora el rendimiento. Si nuestro SQL Server es anterior a 2016 no hará crecer los ficheros a la vez por defecto y deberemos indicarlo con la traza -T1117 en el arranque.

Base de datos TempDB

Hablando de la TempDB, aprovisionaremos un tamaño inicial igual al 25% o 30% del total del tamaño de datos que hayamos estimado que vamos a tener. Repartiremos ese tamaño total entre tantos ficheros como CPUs tengamos con un máximo de 8. Todos los ficheros tendrán el mismo tamaño inicial.

Base de datos Model

SharePoint creará las bases de datos que necesite, por lo que es importante trasladar todas las anteriores consideraciones a nuestra base de datos model a fin de que se puedan aplicar automáticamente en todas las nuevas bases de datos.

Mantenimiento de bases de datos de SharePoint

Como en cualquier otro servidor SQL Server se hace imprescindible configurar un plan de copias de seguridad y un chequeo de integridad de las bases de datos periódicamente. 

En cuanto al mantenimiento de índices y estadísticas tenemos que conocer la versión de SharePoint que se está ejecutando. En SharePoint 2012 o inferior este gestionará el plan de mantenimiento de índices y estadísticas por lo que no deberemos nosotros duplicar ese trabajo. Para SharePoint 2013 o superior si que debemos configurar nuestros planes de mantenimiento con normalidad. Como ya sabéis, en estos casos yo os recomiendo las herramientas de Ola Hallengren.

Conclusión

Hoy hemos aprendido a configurar nuestros servidores SQL Server para alojar las bases de datos de SharePoint. Es importante repetir estos pasos en todos los servidores de la granja de SharePoint para sacar todo el partido de esta aplicación. Tanto si vais a desplegar un nuevo servidor SharePoint como si ya lo tenéis, aplicad estos consejos y los del post de instalación y veréis como mejora el rendimiento. Yo lo hice en un cliente y os aseguro que el volumen de incidencias por lentitud se redujo drásticamente. 

Y ya no me enrollo más, recuerda que puedes dejarme tus comentarios o preguntas al final del artículo, en Twitter o por mail. Hasta la próxima.

Publicado por Roberto Carrancio en Rendimiento, SQL Server, 1 comentario