Mes: junio 2024

Jun

2024

¡Adiós al error 0x851A001A! Instala SQL sin problemas en Windows 11

¿Te encuentras con el error 0x851A001A al instalar SQL en tu nuevo equipo con Windows 11? ¡No te preocupes! Este error es común y tiene una solución sencilla. En este artículo te explico qué es lo que lo provoca y cómo puedes solucionarlo para poner en marcha tu instancia de SQL en cuestión de minutos.

El error 0x851A001A: un obstáculo común

En varias ocasiones me he topado con clientes que presentaban problemas con sus instalaciones de SQL al tratar de realizarlas sobre equipos nuevos en los que se había instalado Windows 11. El error en cuestión se trata del 0x851A001A, y es un error contemplado por Microsoft.

Este fallo se produce durante la instalación de cualquier versión de SQL, debido a que el instalador de SQL no es capaz de realizar ciertas acciones de configuración. Como os digo, este error suele producirse en los equipos con sistemas operativos Windows 11, pero os diré que, en alguna ocasión poco habitual, me he visto en la misma situación con otros sistemas.

¿Qué es el tamaño de sector de disco y por qué es importante?

El tamaño del sector de un disco duro hace referencia a la cantidad de información que puede almacenar cada una de las secciones lógicas en las que se divide. Ya hablamos de este tema sin profundizar tanto en este artículo. Este tamaño es importante ya que afecta a distintos factores:

Eficiencia de almacenamiento: Un sector más grande será capaz de almacenar una cantidad de información mayor, necesitando menos espacio en el disco para guardarla, y, por tanto, optimizando el espacio.
Rendimiento: En general, cuanto mayor sea el tamaño del sector, más rápido realizará las operaciones de lectura y escritura de datos.
Compatibilidad: No todos los sistemas operativos ni todos los programas son compatibles con todos los tamaños de sector.

¿Por qué se produce el error 0x851A001A?

En muchos de los discos actuales podemos encontrar tamaños de sector de 4096 bytes, pero en discos más antiguos podemos encontrar sectores de 512 bytes. Aunque según Microsoft estos tamaños deberían ser compatibles con SQL, es en estos casos cuando nos topamos con nuestro error 0x851A001A.

En este punto, vamos a entrar en el terreno de lo que llamaremos “especulación responsable”, para tratar de explicar qué es lo que está sucediendo en estos casos, ya que he buscado información al respecto, pero no he encontrado ninguna causa concreta. En mi opinión, creo que los discos duros más nuevos, que permiten trabajar con tamaños de sector de disco mayores, en algún punto de la instalación de Windows 11 pasan a emular un tamaño de sector menor, como por ejemplo 4096 bytes, que es compatible con SQL. Sin embargo, debe haber algún error en esta emulación que provoca que SQL detecte que el tamaño del sector del disco, es mayor, y por tanto nos devuelve el error de compatibilidad.

¿Por qué creo esto? Porque de momento no me he topado con este error en equipos que ya estaban en funcionamiento, por ejemplo con un Windows 10 y se han actualizado a Windows 11; y si me ha pasado con equipos nuevos en los que se había instalado Windows 11, donde los discos son más modernos.

En cualquiera de los casos, seguro que estás pensando, todo esto está muy bien, pero ¿cómo lo soluciono? Pues vamos a verlo.

Solución rápida y efectiva

Para solucionar este problema y disfrutar de SQL en tu Windows 11, o cualquier otro sistema, tendrás que modificar el Registro de Windows. Para hacerlo de una forma sencilla, solo tienes que abrir una ventana de Powershell como administrador y seguir estos pasos:

Comprueba el tamaño del sector de tu disco:

 Powershell
 fsutil fsinfo sectorinfo C:

* Recuerda reemplazar C: con la letra de tu unidad de disco.

Modifica el tamaño del sector:

 Powershell
 New-ItemProperty -Path    "HKLM:\SYSTEM\CurrentControlSet\Services\stornvme\Parameters\Device" -Name    "ForcedPhysicalSectorSizeInBytes" -PropertyType MultiString -Force -Value "* 4095"

Comprueba el cambio:

 Powershell
 Get-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Services\stornvme\Parameters\Device" -Name   "ForcedPhysicalSectorSizeInBytes"

Reinicia tu equipo.

¡Instalación de SQL sin errores!

Una vez completado este proceso, podrás instalar SQL en tu Windows 11 sin problemas, y el error 0x851A001A será cosa del pasado.

Recursos adicionales:

Por último, te dejo algunos enlaces con más información al respecto:

https://learn.microsoft.com/en-us/troubleshoot/sql/database-engine/database-file-operations/troubleshoot-os-4kb-disk-sector-size?WT.mc_id=DP-MVP-5440

https://www.zentinels.net/solucion-al-error-0x851a001a-al-instalar-sql-server

https://learn.microsoft.com/en-us/answers/questions/1367064/unable-to-install-sql-server-2019-on-windows-11-ex

Espero humildemente que este pequeño artículo te ayude a resolver este error, y por supuesto, si tienes alguna recomendación adicional, o quieres hacer alguna aportación; te invito a sumarte en los comentarios para que así podamos seguir aprendiendo como comunidad

#SQLServer #Windows11 #Error0x851A001A #InstalacionSQL #SolucionProblemas #Aprendizaje #Somoscomunidad #Tecnología

El conocimiento es poder. El aprendizaje es el camino hacia el poder
John F. Kennedy

Jun

2024

Arreglar CORRUPCIÓN en Base de datos SQL

¿Alguna vez te has encontrado con una base de datos de SQL Server corrupta? En ocasiones podemos encontrar errores de corrupción en bases de datos que se han estropeado debido a un apagado en mitad de una transacción que no ha podido revertirse o a algún otro error de sistema. Cuando esto pasa lo normal es realizar una reparación de la base de datos que elimina los registros erróneos solucionando así el problema. Esto, sin embargo, no parece la mejor de las soluciones y por eso, hoy os traigo una forma de recuperar solo las páginas dañadas desde un backup.

Es importante destacar que esta solución a la corrupción de bases de datos solo la podremos tomar si tenemos un modo de recuperación distinto al simple pues requiere de hacer y restaurar backups de logs. Si este es tu caso estás de suerte.

Paso a paso para recuperar la corrupción

Lo primero que debes hacer es localizar las páginas dañadas haciendo un DBCC CHECKDB, después haz un backup log para salvar todos los cambios al momento actual. Cuando hayas completado el backup log podrás restaurar solo las páginas afectadas del último backup full y hacer otro backup log. En este paso solo te queda restaurar los backup log hasta justo antes de restaurar el backup FULL. Por último restaura el de exactamente después poniendo ya la base de datos online (WITH RECOVERY). De esta manera habrás conseguido salvar la información y solventar el error sin pérdida de datos.

Espero que te haya gustado el video, si es así por favor, deja tu me gusta y suscríbete al canal que nos ayuda mucho. Si tenéis alguna duda o sugerencia, podéis dejarla en Twitter, por mail o dejarnos un mensaje en los comentarios. Y recuerda que también tenemos un grupo de Telegram al que te puede unir. En este grupo estamos creando una comunidad de usuarios y administradores de SQL Server donde cualquiera pueda preguntar sus dudas y compartir sus casos prácticos para que todos seamos mejores profesionales. ¡Hasta la próxima!

Jun

2024

ROWGUIDCOL

Hoy os vengo a hablar de una característica de SQL Server y las bases de datos de SQL en Azure que normalmente no se usa pero que es muy importante. La opción ROWGUIDCOL cuando estamos definiendo el tipo de datos de nuestras tablas.

ATENCIÓN este artículo es de nivel avanzado, no sufras si no entiendes nada ahora mismo. Te recomiendo investigar sobre los nuevos conceptos que te encuentres y no sepas de que van. Yo voy a intentar enlazarte con anteriores artículos relacionados o documentación extra siempre que sea posible.

¿Qué es ROWGUIDCOL y por qué es importante?

ROWGUIDCOL es una propiedad que vamos a poner a nuestras columnas GUID (identificadores globales). Aunque se puede poner en columnas con otros tipos de datos lo normal es usarlo en campos de tipo Uniqueidentifier. Es especialmente útil en entornos con distintas bases de datos pues nos va a permitir que la clave sea única entre todas las bases de datos.

NEWSECUENTIALID

Si además acompañamos la propiedad ROWGUIDCOL con un valor por defecto NEWSECUENTIALID() en lugar del tradicional NEWID() vamos a conseguir un mejor resultado. La diferencia entre estas dos funciones es que mientras NEWID genera un GUID aleatorio NEWSECUENTIALID va a generar un GUID mayor que cualquier otro generado desde el último reinicio del servidor. También está preparado para trabajar correctamente en entornos de clúster por lo que si tienes un balanceo en tu AlwaysOn va a tener en cuenta los valores generados anteriormente en el otro nodo.

NEWSECUENTIALID es mejor en términos de rendimiento ya que no tiene que generar la aleatoriedad de NEWID y, por tanto, consume menos recursos de páginas en la caché. Además usar NEWSECUENTIALID nos va a ayudar a llenar completamente las páginas de datos e índices y a permitir un FILLFACTOR del 100%. Por contra, el hecho de generar identificadores globales mayores puede ser un riesgo de seguridad. Si la privacidad es clave en tus sistemas seguramente prefieras un GUID totalmente aleatorio y que no se pueda estimar cual es el próximo valor.

Usos Prácticos de ROWGUIDCOL

Como ya hemos visto, la propiedad ROWGUIDCOL puede sernos útil en escenarios donde necesitamos una clave primaria que sea única en todas las bases de datos, no sólo en una base de datos individual. Por ejemplo, estamos desarrollando una aplicación que necesita sincronizar datos entre varias bases de datos, usaremos ROWGUIDCOL para asegurar que cada fila tiene un identificador único en todas las bases de datos.

ROWGUIDCOL en la replicación

Además de lo que ya hemos visto, ROWGUIDCOL es extremadamente útil en escenarios de replicación. En la replicación, a menudo es necesario tener una forma de identificar de manera única cada fila en una tabla. ROWGUIDCOL proporciona una forma fácil de hacer esto sin tener que generar manualmente valores únicos.

Si tenemos una replicación de mezcla (Merge Replication) SQL Server usará el campo marcado como ROWGUIDCOL para identificar las filas. Esto puede sernos un inconveniente ya que no podremos luego usar nosotros ese campo para filtros en la replicación. También es importante que sepas que si configuras una replicación de mezcla sobre una tabla con una columna ROWGUIDCOL SQL asignará automáticamente el valor de NEWSECUENTIALID() como por defecto para esta columna.

Conclusión

El tema de los identificadores únicos para nuestros datos da mucho juego, hoy hemos profundizado en uno de sus aspectos más complejos en SQL Server pero siempre se puede ir un poco más allá. Si te has quedado con ganas de más te recomiendo este artículo del blog de Microsoft en el que se explica cómo se ordenan estos uniqueidentifier hexadecimales.

Si tenéis alguna duda o sugerencia, podéis dejarla en Twitter, por mail o dejarnos un mensaje en los comentarios. Y recuerda que también tenemos un grupo de Telegram y un canal de YouTube a los que te puede unir. ¡Hasta la próxima!

Jun

2024

FizzBuzz (T-SQL Reto). Típico en entrevistas de trabajo

Hoy me he encontrado en LinkedIn con una cosa que me ha llamado la atención, Antonio Jurado había publicado un post en el blog mundo-datos respondiendo a un video de Nacho Cardenal. Este último habría publicado hace unos días la resolución al reto de FizzBuzz en Excel. En los comentarios de su publicación original en LinkedIn, Juan José Luna proponía la solución al reto en Access. A esto se sumó Toni (en la publicación que yo vi) resolviendo el reto en DAX. Así que, no vamos a ser nosotros menos y vamos a resolverlo en SQL, ¿no?

El reto FizzBuzz

El reto FizzBuzz es un sencillo desafío de programación que se emplea en las entrevistas de trabajo técnicas para que el evaluador vea la capacidad de escribir código del candidato.

Como digo, el reto es sencillo, debes codificar un algoritmo que, con los números del 1 al 100 devuelva la cadena “Fizz” si el número es múltiplo de 3, “Buzz” si es múltiplo de 5 o “FizzBuzz” si es múltiplo de 3 y de 5.

Esto es lo que buscamos:

FizzBuzz con T-SQL

Esto es sencillo, tenemos que crear una tabla con los números del 1 al 100 y una columna resultado que será FizzBuzz, Fizz, Buzz o el propio número. Vamos a ello.

Paso 1: Crear la tabla FizzBuzz

El primer paso es crear la tabla FizzBuzz, para ello vamos a comprobar primero si existe y en ese caso la borramos y creamos una nueva. Necesitamos un campo numérico que admita los valores del 1 al 100, con un tinyint nos vale, no vamos a usar más de lo necesario. Para el resultado tendremos que almacenar cadenas de texto pero, no siempre van a tener la misma longitud, podrán ser de 1 a 8 caracteres así que usaremos un varchar(8).

Paso 2: Cargar la secuencia de números

Con la tabla ya creada vamos a empezar a cargar los datos, lo primero será cargar los números que luego vamos a evaluar. Para ello empezamos con la sintaxis INSERT INTO ya que la tabla existe de antes. A este insert le vamos a pasar el resultado de una función de tabla que se ha introducido nueva en SQL Server 2022, GENERATE_SERIES. Esta función tendrá como primer parámetro el primer número de nuestra cadena, como segundo el último y, opcionalmente, como tercero el número en el que se va a incrementar el contador. Como este tercer parámetro es opcional y si no ponemos nada va de uno en uno lo vamos a omitir.

Paso 3: Algoritmo FizzBuzz

Llegó el momento de la verdad, hasta ahora solo habíamos preparado el escenario. Tenemos que actualizar nuestra tabla para poner los valores Fizz, Buzz o FizzBuzz cuando sea necesario. Lo primero que tendremos que saber es que en SQL Server podemos usar el operador % para devolver el resto de una división, por lo que si este es igual a 0 será que el número es múltiplo del dividendo que estemos comparando. Una vez tenemos eso resulto nos encontramos con el siguiente reto, para hacerlo de una sola vez tendremos que usar la sintaxis de UPDATE con un CASE dentro de la cláusula SET.

Hacer correctamente el case será nuestro tercer desafío, como sabéis, esta operación evalúa las condiciones en orden y si la primera de ellas se cumple ya no va a pasar por las siguientes. Esto hace que si o si tengamos que empezar por el caso de que un número sea múltiplo de 3 y de 5. A continuación ya podremos evaluar que sea múltiplo de 3 o de 5 en orden indistinto. Para terminar tenemos que devolver el mismo valor si no se ha cumplido con ninguna de las tres condiciones anteriores lo que nos puede dar más de un quebradero de cabeza si no estamos atentos. El tipo de datos del valor que estamos evaluando (el número) no se puede insertar en un campo de texto, antes tendremos que convertirlo o nos encontraremos con un error en la ejecución.

Paso 4: Mostrar los resultados

Ya hemos hecho lo difícil, ahora solo nos queda mostrar los resultados de nuestro trabajo.

Código de FizzBuzz

Ahora que ya hemos resuelto el desafío te dejo el código completo que he utilizado para que lo puedas copiar, editar e investigar tu mismo otras variaciones.

DROP TABLE IF EXISTS FizzBuzz
CREATE TABLE FizzBuzz (Numero tinyint, Resultado varchar(8))

INSERT INTO FizzBuzz (Numero) 
SELECT * FROM GENERATE_SERIES(1, 100)

UPDATE FizzBuzz SET Resultado = CASE 
	WHEN (Numero % 3 = 0) AND (Numero % 5 = 0) THEN 'FizzBuzz'
	WHEN Numero % 3 = 0 THEN 'Fizz'
	WHEN Numero % 5 = 0 THEN 'Buzz'
	ELSE CONVERT(varchar(8),Numero) 
END 

SELECT * FROM FizzBuzz

Conclusión

Así, de una manera sencilla y eficiente hemos resuelto el reto FizzBuzz en T-SQL, espero que te haya servido para aprender aunque sea alguna sintaxis que no conocías. ¿Se te ocurre otra solución posible? ¿Te apetece que hagamos más desafíos de este tipo? Pónmelo en comentarios y lo tendré muy en cuenta.

Jun

2024

Reducir el tamaño de bases de datos SQL

En esta ocasión vengo a explicaros como puedes hacer para reducir el espacio que ocupan nuestras bases de datos liberando el espacio libre que hay en los ficheros. Para ello, tendremos que hacer un Shrink de los ficheros de base de datos. Tendrás que hacerlo tanto en el ficheros de datos como en el de log (o en el que sepamos que existe un problema).

Evita siempre que puedas la operación de reducir de ficheros, sobre todo en los ficheros de datos, ya que consume muchos recursos del servidor y además va a empeorar el rendimiento de nuestra base de datos. Si no queda más remedio o si has eliminado tanta información que merezca la pena hacerlo, ten la precaución de programarlo fuera de horas de trabajo y de reconstruir los índices fragmentados una vez termines.

En los ficheros de log, como en los de TempDB no vas a tener los problemas de fragmentación pero si de consumo de recursos por lo que aunque no tengamos que ser tan estrictos si debemos intervenir con la debida precaución.

Puedes encontrar los script que he usado en el video aquí. Espero que te haya gustado el video, si es así por favor, deja tu me gusta y suscríbete al canal que nos ayuda mucho. Si tenéis alguna duda o sugerencia, podéis dejarla en Twitter, por mail o dejarnos un mensaje en los comentarios. Y recuerda que también tenemos un grupo de Telegram al que te puede unir. En este grupo estamos creando una comunidad de usuarios y administradores de SQL Server donde cualquiera pueda preguntar sus dudas y compartir sus casos prácticos para que todos seamos mejores profesionales. ¡Hasta la próxima!

Jun

2024

Migrar de Azure SQL DB a Azure Managed Instance

Te pongo en situación, tu empresa decidió hace tiempo empezar a desplegar servicios en la nube de azure. En una fase inicial del proyecto se decidió usar bases de datos de Azure SQL sin servidor, la gama de entrada a SQL en Azure. Ha pasado el tiempo y se ha descubierto que el proyecto no puede continuar debido a las limitaciones de esta solución SAAS. Hay que migrar las bases de datos.

¿Por qué migrar y donde?

Como ya te he adelantado en la descripción, el problema es que necesitas alguna de las características de SQL Server que no incluyen las bases de datos de Azure SQL. Sin embargo, sí que sigues convencido de que la mejor opción es un producto SaaS administrado en la nube, con un tiempo de disponibilidad del 99,99%, con actualizaciones automáticas, seguridad de datos avanzada y análisis de registros SQL de Azure. Básicamente no tener que administrar una máquina local o virtual IaaS.

Parece que la solución es clara, necesitas una instancia administrada de SQL en Azure. Las características de Azure MI que no tienen las bases de datos de Azure SQL son:

Consultas entre bases de datos
Usar las bases de datos como publicadoras en replicación.
Copias de seguridad y restauraciones a petición por T-SQL.
Compatibilidad con .NET SQL CLR
Activadores de ámbito de servidor o triggers de inicio de sesión
Captura de datos modificados (CDC)
Acceso a Resource Governor.
Agente de SQL.
Y más…

¿Cómo no migrar?

En este punto te piden a ti, DBA, llevar a cabo esta migración. Parece una tarea sencilla, ¿verdad? Pues vamos a ver que de eso nada. Como acabamos de ver en el apartado anterior, una de las limitaciones de las bases de datos de Azure SQL es que no permiten copias de seguridad por T-SQL. Aunque si tienen copias de seguridad automáticas por parte de Azure, estas solo se pueden restaurar como otra base de datos de Azure SQL, no las vas a poder llevar a una instancia.

Tampoco vas a poder usar una base de datos de Azure SQL como origen de datos en Azure Data Migration Service (DMS) ni en Data Migration Assistant (DMA). Y esto no es todo, tampoco admiten DB Mirroring, AlwaysOn, Log Shipping o Replicación. Estás perdido, solo te queda implementar una solución de copia de datos manual con T-SQL, SSIS o Azure Data Factory lo que te va a suponer mucho esfuerzo y una sobrecarga de trabajo difícil de asumir. Pero, no te preocupes, yo te voy a contar cómo hacerlo de manera fácil.

¿Qué opciones tienes?

Visto lo visto, partiendo de las premisas anteriores lo primero que tienes que asumir es que esto va a ser un proceso manual. Podrías automatizarlo con las alternativas que hemos mencionado antes de T-SQL, SSIS o Data Factory pero eso no es lo que buscas. Necesitas una solución simple, mover los datos y ya está. Para eso tenemos dos opciones o usar el asistente de Import/Export con SSIS en SSMS o usar el asistente para importar/exportar aplicaciones de capa de datos, también en SSMS.

Asume que durante la migración vas a tener un tiempo de inactividad total de las bases de datos. Realmente vas a poder seguir leyendo la base de datos Azure SQL de origen pero si haces cambios es posible que luego no los veas replicados en la Azure MI.

Ahora bien, puedes reducir el tiempo de inactividad migrando las tablas por partes siempre que tu aplicación lo permita. Si tienes unos datos “frios”, una especie de diccionarios con pocos o ningún cambio puedes migrar esas primero sin parar la aplicación para luego reducir el tiempo al migrar solo el resto de tablas.

Migrar con el asistente de import/export de SSIS en SSMS

Este asistente, lo puedes ejecutar desde SSMS y genera un paquete de SSIS básico para la copia de datos. OJO, solo para la copia de datos. Si las tablas no existen si que las va a crear pero no va a crear ningún otro objeto, ni siquiera los índices. No, ni los índices clustered ni las PK ni nada. Por supuesto tampoco va a crear vistas, triggers, funciones, procedimientos, etc…

Paso 1

Como este asistente solo copia datos lo primero que tienes que hacer es crear en tu instancia administrada de Azure la base de datos con todos los objetos de la base de datos. Sin embargo, en este punto no te recomiendo crear ni los triggers ni las Foreign Keys para evitar problemas con la copia de datos. Para generar los script de creación de objetos puedes usar el asistente que incluye el propio SSMS.

Paso 2

Ahora que ya tienes toda la estructura de tu base de datos creada en Azure MI puedes usar el asistente de importación y exportación para copiar los datos. No vamos a profundizar en este punto porque ya lo hemos explicado en este artículo y en este vídeo. Solo vas a tener que elegir el origen y el destino correctos.

Paso 3

Ahora que ya tienes todos los datos copiados es el momento de crear los triggers y las FK que antes hemos dejado pendientes. También debes validar que todo está correcto y ya estaría listo para trabajar en el nuevo entorno.

Migrar con el asistente de import/export de aplicaciones de capa de datos en SSMS

Este asistente, lo puedes ejecutar desde SSMS y genera un archivo bacpac que luego vas a poder importar sobre la base de datos de tu instancia administrada usando el mismo asistente. Es muy parecido a una copia de seguridad tradicional aunque no es exactamente lo mismo. Vas a ver que los pasos son muy simples.

Paso 1

A diferencia del anterior, este asistente no solo copia datos sino que te va a migrar también los objetos. Además, para importarlo, solo vas a poder hacerlo sobre una base de datos nueva así que en este paso vas a exportar directamente los datos de origen en formato bacpac desde tu SSMS. Haz clic derecho sobre la base de datos, ve al menú tareas y ahí a la opción Exportar aplicación de capa de datos…

Paso 2

Es el momento de restaurar en el destino. Conectate con SSMS a tu instancia administrada de Azure y con clic derecho sobre “bases de datos” ve a restaurar aplicación de capa de datos. Sigue los pasos del asistente para importar tu archivo bacpac.

Paso 3

Ahora que ya tienes todos los datos copiados es el momento de validar que todo está correcto y ya estaría listo para trabajar en el nuevo entorno.

Otras opciones

Existe un tercer método simple que no te había comentado hasta ahora pero que también te puede servir para migrar tus datos. Es bastante más sencillo que los anteriores pero su uso queda limitado a bases de datos realmente pequeñas. Esta tercera opción consiste en generar los scripts de base de datos igual que has hecho en el primer paso de la primera solución que te he enseñado pero, en las opciones avanzadas, seleccionar también que genere los script para migrar los datos. De esta manera te generará los scripts con un insert por cada registro de cada tabla que tengas. Como ves te va a mover los datos pero es del todo ineficiente y solo es para bases de datos con pocas tablas y muy pocos registros.

Conclusión

Has visto las formas sencillas de migrar tus datos de una base de datos de Azure SQL a una instancia administrada de Azure. Con estos métodos vas a poder salir airoso de esta difícil tarea. Ahora ya si te quieres complicar te recomiendo crear un paquete SSIS que copie los datos con un bucle por cada una de las bases de datos en tu servidor de bases de datos de Azure SQL y lo que se te ocurra. A mi es la solución que más me gusta pero, cierto es, que solo merece la pena si las que tienes que migrar son muchas bases de datos.

Jun

2024

Detectando BLOQUEOS en SQL Server y Azure SQL

Cuando trabajamos con bases de datos SQL Server, los bloqueos pueden ser una de las características de implementación que más dolores de cabeza nos pueden dar como DBAs. A los usuarios también, por supuesto, pero ellos trasladarán sus quejas a nosotros.

Por esto, en el vídeo de hoy, te enseño a detectar bloqueos en SQL Server o Azure SQL. Gracias a procedimientos integrados de sistema como sp_who o sp_who2 podremos verlo de una forma muy básica. Si queremos más nivel de detalle podremos recurrir a procedimientos de terceros como sp_who3, sp_whoisactive o sp_BlitzWho.

Si queremos detectar un bloqueo de una forma rápida y ligera, los procedimientos de sistema sp_who y sp_who2 son un gran aliado. Sin embargo, la información que nos van a mostrar es más bien justa. Si tenemos ocasión, siempre será recomendable de recurrir a procedimientos más completos como los citados en el vídeo.

También podremos hacer uso del siguiente script que nos muestra los procesos con bloqueos:

SELECT
 DB_NAME(sp.dbid) as [DBname],
 sp.spid,
 CASE
  WHEN (ecid > 0) THEN 'Parallel process, false alert'
  ELSE ''
  END as 'Parallel?',
 blocked,
 loginame,
 hostname,
 program_name,
 cmd,
 st.text as SQL,
 sp.status,
 login_time,
 last_batch,
 GETDATE() as [current_time],
 waittime,
 lastwaittype,
 waitresource
FROM sys.dm_exec_requests er 
CROSS APPLY sys.dm_exec_sql_text(er.sql_handle) st
JOIN sys.sysprocesses sp 
 ON er.session_id = sp.spid
WHERE blocked <> 0
 OR spid IN (SELECT blocked FROM sys.sysprocesses)

Como ves, el script hace uso de las vistas de administración dinámica de sistema sys.dm_exec_request y sys.sysprocesses para localizar los bloqueos. Además de la función sys.dm_exec_sql_text para devolver el texto de la consulta que está ejecutando esa sesión. En determinadas ocasiones, dependiendo del bloqueo, es posible que este script no resuelva debido a la función. En esos casos comenta esa parte del código para por lo menos localizar los bloqueos.

Mes: junio 2024

¡Adiós al error 0x851A001A! Instala SQL sin problemas en Windows 11

El error 0x851A001A: un obstáculo común

¿Qué es el tamaño de sector de disco y por qué es importante?

¿Por qué se produce el error 0x851A001A?

Solución rápida y efectiva

¡Instalación de SQL sin errores!

Recursos adicionales:

Arreglar CORRUPCIÓN en Base de datos SQL

Paso a paso para recuperar la corrupción

FizzBuzz (T-SQL Reto). Típico en entrevistas de trabajo

El reto FizzBuzz

FizzBuzz con T-SQL

Paso 1: Crear la tabla FizzBuzz

Paso 2: Cargar la secuencia de números

Paso 3: Algoritmo FizzBuzz

Paso 4: Mostrar los resultados

Código de FizzBuzz

Conclusión

Detectando BLOQUEOS en SQL Server y Azure SQL

Colabora con nosotros

Entradas recientes

Etiquetas

Comentarios recientes