DBA

Cloud SQL en Google Cloud Platform

/ bonisql / Deja un comentario

Recientemente he estado considerando la opción de Cloud SQL para SQL Server ofrecida por Google Cloud Platform (GCP). Esta es la plataforma de servicios en la nube ofrecida por el gigante Google. En terminos de servicios cloud, parece que aún no está al nivel de Amazon Web Services (AWS) o Microsoft Azure. Sin embargo, el crecimiento de GCP en los último años dos años ha sido significativo. Sigue leyendo →

Creando nuestro laboratorio de Elasticsearch con Hyper-V

/ bonisql / Deja un comentario

Para crear nuestro laboratorio de Elasticsearch en un equipo Windows, con el que poder experimentar más adelante 😊, una buena opción es usando Hyper-V. Este es un software de virtualización que ofrece Microsoft y que se puede instalar en varias versiones de Windows 10 de forma gratuita.

Objetivo

Vamos a crear un cluster con las siguientes características:

  • Nombre del cluster: es-cluster-lab
  • Número de nodos: 3
  • Nombre de los nodos: elasticsearch-lab-{1..3}.localdomain

Sigue leyendo →

Query Store: Ejemplos prácticos

/ bonisql / Deja un comentario

En mi primer artículo sobre Query Store, hace ya bastante tiempo, comenté que escribiría otro incluyendo ejemplos de configuraciones, monitorización y consumo de recursos. Bien, ese día ha llegado!

Código de ejemplo de configuración

USE master;
GO

ALTER DATABASE [NombreDeTuDB]
	SET QUERY_STORE = ON
	(
		OPERATION_MODE = READ_WRITE
		, CLEANUP_POLICY = (STALE_QUERY_THRESHOLD_DAYS = 14)
		, DATA_FLUSH_INTERVAL_SECONDS = 600
		, INTERVAL_LENGTH_MINUTES = 10
		, MAX_STORAGE_SIZE_MB = 512
		, QUERY_CAPTURE_MODE = AUTO
		, SIZE_BASED_CLEANUP_MODE = AUTO
		, MAX_PLANS_PER_QUERY = 7
	);

Puedes ver que los parámetros se explican en el citado artículo. Como siempre, te recomiendo probar bien la configuración en entornos de pre-producción, ya que la carga de trabajo de tu Base de Datos influye de forma directa. Dicho esto, este ejemplo de configuración es funcional y no he tenido problemas con ello.

Código de ejemplo para monitorizar el uso de disco de Query Store

Este código lo vamos a desglosar por pasos:
1) Creamos una base de datos (opcional) y una nueva tabla para guardar los datos que vamos a monitorizar:

USE master;
GO

CREATE DATABASE DBA_Admin;
GO

USE DBA_Admin;
GO

CREATE TABLE dbo.QueryStoreSizeHistory (
	current_storage_size_mb	BIGINT NOT NULL
	, max_storage_size_mb	BIGINT NOT NULL
	, date_time				DATETIME2(2) DEFAULT(GETDATE()) NOT NULL
);

2) A continuación podemos crear un SQL Agent Job, que se lance cada N horas, y que  sólo va a ejecutar el siguiente código de T-SQL:

USE DBA_Admin;
GO
INSERT INTO dbo.QueryStoreSizeHistory (
current_storage_size_mb
, max_storage_size_mb
)
SELECT current_storage_size_mb
, max_storage_size_mb
FROM MiDB.sys.database_query_store_options;

Fíjate que la vista del sistema sys.database_query_store_options existe a nivel de la Base de datos donde QS está configurado. Por lo que hace falta usar la referencia en tres partes (NombreDB.NombreEsquema.NombreTabla).

3) Finalmente tras dejar pasar un tiempo, puedes comprobar como se ha ido usando el espacio asignado a Query Store:

SELECT *
	FROM DBA_Admin.dbo.QueryStoreSizeHistory
	ORDER BY date_time;

Mencionar que esta tabla de monitorización no tiene índices de ningún tipo ni PK. Esto es así poque su tamaño no debería superar unos pocos MBytes. Está pensanda para una comprobación inicial sobre cómo de rápido se llena el espacio de QStore. Si quieres mantener esta monitorización de forma indefinida, mi recomendación sería incluir un paso de limpieza/borrado de los registros más antiguos.

Tras un tiempo, con QS en funcionamiento, deberías echar un vistazo a los informes en tu Base de Datos a través de la interfaz de SQL Server Management Studio (SSMS):

2019-04-26_00h56_29

Lo recomendable en este punto, es que lo pruebes y veas por ti mismo lo útil que puede llegar a ser. Puedes usar también los ejemplos que utilicé en mi última presentación sobre Query Store , mira el link en la sección de comentarios.

Aparte de los informes predefinidos de SSMS, te recomiendo echar un vistazo a las consultas del sistema que vienen como parte de Query Store, y que te brinda toda la personalización que se te ocurra en tus comprobaciones. En la documentación de MSSQL puedes encontrar un buen puñado de ejemplos que usan esas vistas del sistema. Resultan especialmente interesantes las consultas bajo la sección Performance Auditing and Troubleshooting.

Y eso es todo por hoy, espero que te haya sido de ayuda. Cualquier pregunta, puedes enviarme un mensaje o dejar un comentario.

¡Hasta el próximo artículo!

Empezando con QUERY STORE

/ bonisql / Deja un comentario

Esta es una nueva de las nuevas características en la versión 2016, de la que se está hablando mucho en los círculos de SQL Server ¿Está lista para ser usada? ¿O es una de esas características a las que hay que dejar evolucionar hasta que pasen unas versiones más? ¿Hay unas buenas prácticas ya? Yo te recomiendo ante todo que lo pruebes por ti mismo, aunque también puedes leer un blog y ver qué dicen… ¡Ahí vamos!

Lo que ofrece Query Store

Nos ofrece la creación de forma automática un registro perdurable de consultas, planes de ejecución y estadísticas. Esta funcionalidad se activa a nivel de base de datos, no de instancia. Lo cual veo positivamente, porque lo hace más adaptable. Habrá instancias donde te interese tenerlo activado para todas las BBDD de usuario y otras en las que sólo para algunas.

Si habéis hecho alguna vez consultas a las vistas dinámicas del sistema sys.dm_exec_query_stats o sys.dm_exec_procedure_stats para medir el rendimiento de alguna consulta o procedimiento, incluso combinadolo con la función sys.dm_exec_query_plan, posiblemente habréis pensado “Qué pena que toda esta información no sea persistente y se pierda con un reinicio del servidor o servicio de SQL…”

Bueno… ¡Es justo lo que hace Query Store! Y varias cosas más como veremos en este y futuros artículos.

Configurando Query Store

Query Store, en adelante QS, tiene una configuración por defecto que puede cambiarse a conveniencia. Recomiendo leer detenidamente todas estas opciones de configuración en la msdn, las detallo todas a continuación y comento algunas de ellas:

  • OPERATION_MODE: Puede ser READ_WRITE, que permite la recopilación y consulta de datos por parte de Query Store. También puede ser READ_ONLY, o sólo consulta, y dejan de actualizarse las estadísticas, los planes, etc.
  • CLEANUP_POLICY: Se usa junto a la keyword STALE_QUERY_THRESHOLD_DAYS y sirve para especificar cuanto tiempo queremos retener los datos recopilados, por defecto son 367 días.

Si la principal utilidad de QS es analizar el rendimiento de la base de datos, y dar un mejor soporte al troubleshooting, guardar los metadatos de todo un año o incluso varios meses parece muy exagerado. Para este propósito de resolver/investigar un problema de rendimiento, pondría un valor de una semana como mucho. Con un valor bajo, mantenemos a ralla el tamaño máximo que pueda necesitar QS.

  • DATA_FLUSH_INTERVAL_SECONDS: Para indicar con qué frecuencia quieres que los datos recopilados se graben en disco, se hagan persistentes. El valor por defecto son 900 seg (15 min).

Hay que tener en cuenta que en caso de un apagón se perderá todo lo que QS tenga en memoria, si este valor es alto entonces potencialmente puedes perder todos esos datos de los últimos N-1 minutos, donde N es el valor configurado. Por otro lado, si este valor es muy bajo, QS estará grabando cada pocos segundos en disco. Es algo que hay que ponderar y que dependerá de la memoria disponible y el rendimiento del almacenamiento.

  • MAX_STORAGE_SIZE_MB: Para indicar el tamaño máximo de almacenamiento asignado a QS. Por defecto son 100 MB. Si Query Store alcanza su tamaño máximo asignado, automáticamente su OPERATION_MODE pasa a READ_ONLY.

Este valor dependerá de la carga de trabajo, workload, que tenga la base de datos. Un buen valor será aquél que no cause frecuentes llenados del QS.

  • INTERVAL_LENGTH_MINUTES: Intervalo de tiempo para agregar datos. Valores permitidos: 1, 5, 10, 15, 30, 60 y 1440. Por defecto es cada hora.

Este valor es muy importante, ya que afecta al espacio que QS necesitará. Si se agregan datos cada pocos minutos, hará falta más espacio.

  • SIZE_BASED_CLEANUP_MODE: Hace que QS haga un mantenimiento automático cuando se acerque al MAX_STORAGE_SIZE_MB. Valores permitidos: OFF y AUTO, cuando llega al 90% de la capacidad, elimina las más antiguas y menos costosas hasta llegar al 80%.

Esta es una opción muy importante para evitar que el QS se llene, se ponga en modo READ_ONLY y por tanto deje de recopilar datos y sernos útil. El citado cleanup no debería ocurrir más de una vez cada N días, si no podrías estar perdiendo información útil en caso de querer investigar un problema en las últimas 24 horas por ejemplo.

  • QUERY_CAPTURE_MODE: Indica el modo actual de captura de datos de ejecución. Valores posibles:

ALL, captura todas las consultas. Es el valor por defecto.:

AUTO, recopila todas las consultas relevantes. Se basa en número de ejecuciones y consumo de recursos.:

NONE deja de capturar nuevas consultas, pero continúa recopilando datos para las que existían.:

La opción AUTO sin duda ayudará a mantener el tamaño de QS a raya.:

  • MAX_PLANS_PER_QUERY: Indica el número máximo de planes de ejecución que se pueden guardar para cada consulta. Por defecto es 200.

El valor por defecto es realmente alto. Personalmente lo reduciría en función de STALE_QUERY_THRESHOLD_DAYS. Si vamos a retener información para una semana, MAX_PLANS_PER_QUERY podría ser por ejemplo 7, para el caso extremo de una query que cambie su plan de ejecución cada día.

Eso es todo por ahora, espero que como introducción os haya sido útil. En un próximo artículo mucho más práctico sobre Query Store, comprobaremos algunos ejemplos de configuraciones, monitorización y consumo de recursos.