Problema: Recientemente hemos migrado algunas de nuestras bases de datos de SQL Server a Azure y queremos asegurarnos de que estas bases de datos respondan. Necesitamos configurar una verificación de latido programada contra las bases de datos de Azure para monitorear su estado. ¿Qué opciones están disponibles para automatizar este tipo de verificación?

Solución: Una opción que se me ocurre es utilizar PowerShell para verificar periódicamente el estado de las bases de datos de Azure. En esta publicación del blog, exploraremos algunos scripts de PowerShell que se pueden utilizar para realizar esta función.

Primero, echemos un vistazo a un script de PowerShell que verifica las siguientes condiciones para una base de datos:

1. La base de datos está presente
2. La base de datos no se está restaurando actualmente
3. La base de datos está en línea
4. El acceso a la base de datos no está impedido por el uso actual de recursos

Aquí está el script de PowerShell:

Function Heartbeat-AzureDBs {
    Param(
    [string]$server
    , [string]$database
    , [string]$username
    , [string]$password
    )
    Process
    {
        $scon = New-Object System.Data.SqlClient.SqlConnection
        $scon.ConnectionString = "Data Source=$server.database.windows.net;Initial Catalog=$database;Connection Timeout=10;User ID=$username;Password=$password;"
        
        $cmd = New-Object System.Data.SqlClient.SqlCommand
        $cmd.Connection = $scon
        $cmd.CommandText = "SELECT NEWID()"
        
        $timer = New-Object System.Diagnostics.StopWatch
        
        try 
        {
            $timer.Start()
            $scon.Open()
            $sqlread = $cmd.ExecuteReader()
            while ($sqlread.Read())
            {
                $returnvalue = $sqlread.GetValue($value)
                $time = $timer.Elapsed.ToString()
            }
            Write-Host "$database.  Número de verificación: $returnvalue ($time)."
        }
        catch [Exception]
        {
            ### Otro alerta
            Write-Warning $_
        }
        finally
        {
            $scon.Dispose()
            $cmd.Dispose()
            $timer.Stop()
        }
    }
}

Heartbeat-AzureDBs -server "" -database "" -username "" -password ""

Algunos puntos clave para el código anterior:

• Este script no lee de una tabla específica, pero si la base de datos está fuera de línea y ha configurado una alerta, le notificará.
• El tiempo de espera para la verificación de latido está configurado en 10 segundos, pero puede ajustar este valor según sus requisitos.
• El script devuelve el tiempo transcurrido para la respuesta de la consulta, lo cual puede ser útil para detectar patrones en los procesos de Azure.

Si desea realizar verificaciones de latido para varias bases de datos en el mismo servidor de Azure, puede utilizar la biblioteca SMO (SQL Server Management Objects) y recorrer todas las bases de datos que no sean de sistema. Aquí hay un ejemplo de cómo lograr esto:

### Bucle de bases de datos SMO, excluyendo la base de datos maestra
Function Loop-AzureDBs {
    Param(
    [string]$server
    , [string]$smolibrary
    , [string]$username
    , [string]$password
    )
    Process
    {
        Add-Type -Path $smolibrary
        
        $smoscon = "Data Source=$server.database.windows.net;Initial Catalog=master;User ID=$username;Password=$password;"
        $servercon = New-Object Microsoft.SqlServer.Management.Common.ServerConnection
        $servercon.ConnectionString = $smoscon
        $srv = New-Object Microsoft.SqlServer.Management.SMO.Server($servercon)
        
        foreach ($db in $srv.Databases | Where-Object {$_.Name -ne "master"})
        {
            $dbname = $db.Name
            Heartbeat-AzureDBs -server $server -database $dbname -username $username -password $password
        }
    }
}

Loop-AzureDBs -server "" -smolibrary "" -username "" -password ""

Utilizando el script anterior, puede recorrer todas las bases de datos que no sean de sistema en un servidor de Azure y realizar la verificación de latido para cada base de datos.

Es importante tener en cuenta que si un latido falla debido al uso de recursos, es posible que deba reestructurar su entorno o modificar su lógica de código/aplicación para evitar este problema. Sin embargo, incluso si un latido falla, no significa necesariamente que la base de datos esté fuera de línea. Múltiples fallas de latido generalmente indican una base de datos fuera de línea.

En conclusión, la automatización de verificaciones de latido para bases de datos de Azure en SQL Server puede ayudar a garantizar la capacidad de respuesta y disponibilidad de sus bases de datos. Mediante el uso de scripts de PowerShell, puede verificar periódicamente el estado de sus bases de datos de Azure y tomar las acciones apropiadas en función de los resultados.