SQL Server Express - Automatización de backup en ruta UNC

Como es sabido, la edición de SQL Server Express no puede utilizar el servicio SQL Server Agent, motivo por el cual, a priori, y con el software tal como es, no se puede definir una rutina de backup u otros Jobs planificados, como planes de mantenimiento para las bases de datos.

El objeto de este artículo es cubrir esta necesidad sin incurrir en licenciamiento Standard de SQL ni licencias de terceros al efecto.

Para ello, crearemos un archivo ejecutable por lotes en el que definiremos una conexión a la instancia de base de datos de turno, ejecutaremos una query SQL por la que, para este caso de uso, crearemos un Backup de nuestra base de datos, seguidamente borramos backups anteriores, y a continuación se comprime el backup de la base de datos en una ruta UNC. Recordemos que aún teniendo SQL Standard solo se puede hacer backups en rutas locales, por lo que este script también acomete esa particularidad.

El script scriptBackup.bat sería de esta manera:

@echo Off

REM Borramos copias de seguridad viejas, o no, esto es opcional

del "D:\VMs\*.bak

REM Borramos el backup comprimido anterior de la ruta que lo alojase, o no, esto es opcional

del \\127.0.0.1\rutaPOC\Copia_Diaria.zip

REM Creamos backup de la base de datos

sqlcmd -S tcp:127.0.0.1\SQLEXPRESS,1433 -i d:\VMs\backup.sql

REM Comprimimos y enviamos a la ruta de almacenamiento el backup

"C:\Program Files\7-Zip\7z.exe" a -mx9 -y "\\127.0.0.1\rutaPOC\"Copia_Diaria.zip "D:\VMs\*.bak"

El archivo backup.sql al que se refiere el script anterior, sería como sigue:

USE master

BACKUP DATABASE [POC_Backup]

TO DISK = N'D:\VMs\POC-Backup.bak'

WITH NOFORMAT, NOINIT, 

NAME = N'POC_Backup-Full Database Backup',

SKIP, NOREWIND, NOUNLOAD,  STATS = 10

GO

Por último, crearemos una planificación en el programador de tareas de Windows, con la periodicidad y detalle que nuestra situación precise.

SQL Server: Troubleshooting Performance

En ocasiones el servicio SQL puede estar consumiéndose el tiempo de CPU por completo y de acuerdo al monitor de rendimiento o al administrador de tareas no sabremos más que sqlservr.exe utiliza casi el 100% del tiempo de CPU.

Obviamente la solución no puede pasar por reiniciar el servicio o el servidor, especialmente en ambientes de producción, porque, además, tampoco resolverá el problema subyacente.

Para poder acotar de forma específica actores dentro del servicio SQL que puedan incidir en el uso de los recursos del sistema, a continuación, propondremos las siguientes consultas para obtener las oportunas evidencias para cada caso.

/* PETICIONES MÁS LENTAS */

/* tiempo en microsegundos */

/* NÚMERO DE CONEXIONES ABIERTAS */

/* TIEMPO DE EJECUCIÓN DE FUNCIONES Y PROCEDIMIENTOS ALMACENADOS, CONTEO Y MEDIA */

/* tiempo en microsegundos */

/* DESCUBRIR QUIÉN ESTÁ BLOQUEANDO */

/* USE COLUMNA BlkBy */

/* VER QUÉ CONEXIÓN ESTÁ HACIENDO QUÉ COSA */

/* ENCUENTRAS ÍNDICES SIN UTILIZAR – PUEDE AFECTAR ESCRITURAS EN EL LOG */

/* DMV PARA ENCONTRAR ÍNDICES ÚTILES: */

/* TOP 10 DE CONSULTAS */

/* MONITOR DE PLANES DE CONSULTAS */

/* COMPROBAR EL TAMAÑO DE OBJETOS DE LA BASE DE DATOS */

-- para comprender quién hace qué, presentación/vista alternativa

-- todos los índices fragmentados en la base de datos actual, % de fragmentación>30%

-- reconstruir todos los índices online

-- reconstruir un índice online en particular

Puedes descagar las queries AQUÍ.