El papel del DBA y la administración de SQL Server en la nube.

Les comparto un artículo publicado en la revista SQL Magazine. Que habla del role del DBA cuando migramos a la nube. He de decir que no estoy de acuerdo en algunos de los puntos tratados acá pues en algunos casos se expone como que la configuración de soluciones de alta disponibilidad híbridos (On Premise - Cloud) son sumamente complejos. Si bien es cierto no son configuraciones step By step son procesos relativamente simples que no requieren habilidades extra a las que un buen DBA ya trae consigo. Aparte de lo mencionado anteriormente si es de recalcar que los que somos DBAs siempre pensamos que tareas tendríamos que realizar con la llegada de SQL Azure Cloud Database pues muchas de las tareas como respaldos, administración del disco ya no serían de administración nuestra.

Acá les dejo el link para que saquen el rato para leerlo. 

 Saludos.

 http://sqlmag.com/cloud/dba-cloud-threat-or-opportunity

Cuando el Detach y el Attach no es suficiente.

Cuantas veces nos han dicho que para mover una base de datos en SQL Server es tan sencillo como hacer un Detach, mover archivos y luego hacer un Attach de nuevo para que la base de datos quede operacional? 

La respuesta es simple : N veces. En un mundo ideal en donde existe el orden, la documentación y a planeación debería de ser así de simple, pero la realidad es otra, por este motivo es necesario el documentar la localización real de mis bases de datos para evitar sorpresas cuando requiera realizar este tipo de tareas, ya sea por migraciones, simple re localización de archivos o cual sea el motivo.

Recientemente me encontré un caso interesante. La tarea era sencilla a simple vista. El requerimiento "Necesito mover las bases de datos de unidad porque no tengo espacio"

Formas de realizar el proceso hay muchas, algunos pensarán, "Bueno si tengo respaldos de las bases de datos puedo hacer restore de las BD y listo", claro, puede ser, siempre y cuando la app no sea tan transaccional que pueda darme el lujo de restaurar un respaldo de hace unas horas o bien que pueda respaldar la BD en el preciso momento de la restauración. Aun así administrativamente es un proceso un poco mas complejo que realizar el proceso de Detach y Attach. 

Para este caso utilicé una serie de queries que me permitieron documentar bien la ubicación de las bases de datos.

--El primero de ellos me muestra la ubicación específica de los archivos para una sola BD, en este caso la llamada TestDB

SELECT name, physical_name as PhysicalPath FROM sys. master_files

WHERE DB_Name(database_id)='Testdb'

Si requieren conocer las rutas de Todas las bases de datos incluyendo las de sstema pueden utilizar el siguiente query.

--Si requieren mover tambien las BD de Sistema, utilizan este query para documentar su ruta

SELECT D.name as DatabaseName,MF.name as LogicalName, physical_name as PhysicalPath FROM sys. master_files MF

INNER JOIN sys.databases D on MF.database_id=D.database_id

order by 1

Este escenario que ustedes ven en la imagen es probablemente lo que ustedes se vayan a encontrar en la vida real, no digo que en todo lugar sea así, pero al menos en un 80% de empresas si lo es, principalmente en aquellas pequeñas o medianas empresas. El query es útil si requiero documentar también la ubicación de las bases de datos de sistema (Cuyo proceso de re localización de archivos es distinto y repasaremos luego su proceso)

Ahora bien si lo que busco es únicamente conocer la ruta de las bases de datos de usuario, ejecuto el siguiente script.

--Si no requieren mover las BD de sistema, solo la TEMDB entonces se utiliza este query para documentar las rutas

SELECT D.name as DatabaseName,MF.name as LogicalName, physical_name as PhysicalPath FROM sys. master_files MF

INNER JOIN sys.databases D on MF.database_id=D.database_id

WHERE D.database_id NOT IN(1,3,4)

order by 1 

Cual es la importancia de documentar? Expongamos el siguiente caso.

Supongamos que ustedes dicen conocer su ambiente de base de datos, y simplemente realizan un detach de la base de datos que desean mover, sin haber documentado su ruta original, seguidamente van a buscar la ruta en donde ustedes creen tener la Base de Datos, pasan los archivos y realizan el proceso de Attach. A los minutos comienzan a recibir llamadas que los pedidos que se han hecho en los últimos días no se ven reflejados en pantalla. En este momento ustedes se preguntan "Cómo es posible? si yo solo hice un Detach y un Attach"

Probablemente eso es cierto, pero lo hice a partir de los archivos correctos? Probablemente muchos otros DBA o personal de TI que en algún momento haya hecho tareas de DBA copió archivos de esa base datos en alguna otra ruta.

Este tipo de casos pueden suceder cuando no se tiene documentada la ruta real de las bases de datos. Dicho esto, les recomiendo la utilización de estos scripts para evitar pasar un mal rato en lo que normalmente es un simple proceso de Detach y Attach. 

Saludos.

Problemas de rendimiento y el horario de ejecución de Jobs

En días pasados estaba identificando posibles cuellos de botella en una base de datos SQL Server 2012, pues se reportaban problemas serios de rencimiento en la aplicación a la misma hora todos los días de la semana. 

Aunado a la configuración de contadores de rendimiento, ejecución de SQL Server Profiler, utilicé algunas de las vistas de Su Magestad Glen Berry  de SQLSkills para identificar cuales procesos automáticos se ejecutan durante el día. La vista original de una idea general de los Jobs que se ejecutan en SQL Server. Sin embargo la vista no descarta aquellos jobs inactivos y tampoco muestra las horas de ejecución. por lo que me tomé la libertad de modificar la vista e incluir un par de columnas necesarias. La fecha y hora de la próxima ejecución del Job, además de modificar para que únicamente despliegue aquellos Jobs activos. De esta forma podemos identificar claramente cuales son los procesos que se ejcutan en determinado momento. 

Ya de esta manera logramos identificar cuales procesos nos estaban generando los problemas de sobrecarga en el servidor de base de datos y moverlos a horas en que la carga es menor y de paso afinar los SP que se ejecutan.

Acá les dejo el script modificado.

--******************************************************************************
--* Copyright (C) 2014 Glenn Berry, SQLskills.com
--* All rights reserved. 
--*
--* For more scripts and sample code, check out 
--* http://sqlskills.com/blogs/glenn
--*
--* You may alter this code for your own *non-commercial* purposes. You may
--* republish altered code as long as you include this copyright and give due credit. 
--*
--*
--* THIS CODE AND INFORMATION ARE PROVIDED "AS IS" WITHOUT WARRANTY OF 
--* ANY KIND, EITHER EXPRESSED OR IMPLIED, INCLUDING BUT NOT LIMITED 
--* TO THE IMPLIED WARRANTIES OF MERCHANTABILITY AND/OR FITNESS FOR A
--* PARTICULAR PURPOSE. 
--*

--******************************************************************************

--Modified by Adrian Miranda in order to include next Exection Date, time and status

-- Get SQL Server Agent jobs and Category information (Query 4) (SQL Server Agent Jobs)

SELECT sj.name AS [JobName], sj.[description] AS [JobDescription], SUSER_SNAME(sj.owner_sid) AS [JobOwner],
sj.date_created, sj.[enabled],jq.next_run_date,CASE WHEN LEN(jq.next_run_time)= 6 THEN SUBSTRING(CAST((jq.next_run_time) AS VARCHAR),1,2) + ' hour(s), ' ELSE SUBSTRING(CAST((jq.next_run_time) AS VARCHAR),1,1) + ' hour(s), ' END + SUBSTRING(CAST(( jq.next_run_time) AS VARCHAR),3,2) + ' min ' + SUBSTRING(CAST(( jq.next_run_time) AS VARCHAR),5,2) + ' sec' AS Next_Run_Time, sj.notify_email_operator_id, sc.name AS [CategoryName]
FROM msdb.dbo.sysjobs AS sj WITH (NOLOCK)
INNER JOIN msdb.dbo.syscategories AS sc WITH (NOLOCK)
ON sj.category_id = sc.category_id
INNER JOIN msdb.dbo.sysjobschedules jq
ON sj.Job_id = jq.job_id
INNER JOIN msdb.dbo.sysschedules s ON s.schedule_id=jq.schedule_id
WHERE sj.[enabled] = 1 AND s.enabled=1

ORDER BY sj.name OPTION (RECOMPILE);