¡¡Hola, chicos!!
Se acerca fin de año, todos se están preparando para la Nochevieja y por eso me gustaría compartir contigo el “TOP 10 artículos técnicos del 2019 que más te gustaron”, es decir, los artículos que publiqué en 2019 y que más viste. Espero que hayas disfrutado de esta breve lista y que algún artículo te pueda resultar útil si no lo has visto antes.

Sin más, vayamos a la lista.

#10 – SQL Server – Cómo evitar ataques de fuerza bruta a su base de datos

En este artículo, demostré cómo ocurren los ataques de fuerza bruta en SQL Server y cómo intentar defenderse contra este tipo de ataque.

El ataque de fuerza bruta es la técnica más sencilla y que requiere más tiempo para acceder a sistemas y bases de datos. Consiste en utilizar bases de datos de contraseñas para probar cada una de estas contraseñas o realizar una comprobación sistemática de todas las claves y contraseñas posibles hasta que una de ellas pueda iniciar sesión con éxito en el destino.

Este tipo de ataque se puede utilizar cuando no es posible aprovechar otras debilidades de un sistema criptográfico (si las hubiera) que facilitarían la tarea, ya que el tiempo necesario para probar todas las contraseñas posibles puede ir desde unos pocos segundos (3 caracteres) hasta miles de años, dependiendo del número de caracteres de la contraseña y de la complejidad de los caracteres utilizados.

#9 – SQL Server – Cómo identificar y recopilar información de consultas de larga duración utilizando Eventos Extendidos (XE)

En este artículo, compartí contigo cómo identificar y recopilar información de consultas de larga duración utilizando Eventos Extendidos (XE), en un artículo muy similar al SQL Server: cómo identificar y recopilar información de consultas de larga duración utilizando Trace (SQL Server Profiler), que utiliza la tecnología Profiler (Trace).

Lo que me motivó a escribir este artículo fue que Profiler es una característica que ha estado marcada como obsoleta durante mucho tiempo, es una tecnología mucho más antigua y el código no es amigable ni legible en absoluto. Entonces, pensando en brindarles una solución más moderna e intuitiva, decidí compartir esta solución usando XE.

#8 – SQL Server – Consejos para ajustar el rendimiento: ¿Conversión implícita? ¡NUNCA MÁS!

En este artículo me gustaría comentar un problema de rendimiento en consultas que encontramos mucho aquí en nuestra vida diaria en Fabricio Lima – BD Solutions, una de las mejores y más reconocidas empresas de Performance Tuning de Brasil. Estamos hablando de algo que muchas veces es terriblemente sencillo de resolver y de conversión implícita, inexplicable y extremadamente común.

La conversión implícita ocurre cuando SQL Server necesita convertir el valor de una o más columnas o variables a otro tipo de datos para permitir la comparación, concatenación u otras operaciones con otras columnas o variables, ya que SQL Server no puede comparar una columna varchar con otro tipo int, por ejemplo, si no convirtió una de las columnas para que ambas tengan el mismo tipo de datos.

#7 – SQL Server – ¿Cuándo debería usar ORDER BY en la consulta y cuándo no debería usarlo en absoluto?

En este artículo, compartí contigo cuándo deberías usar ORDER BY y cuándo no deberías usarlo en absoluto, porque no tiene ningún efecto en la práctica y solo hace que nuestra consulta demore más y consuma más recursos.

El objetivo principal de este artículo era romper el mito de que los datos se ordenan físicamente en la tabla cuando se hace INSERT... FROM SELECT y ORDER BY, lo que hace que muchos programadores insistan en usar ORDER BY en las operaciones INSERT, un escenario que encuentro mucho al consultar a clientes y es mucho más común de lo que me gustaría.

#6 – SQL Server – NOLOCK vs READPAST: ¿Conoce la diferencia entre los dos?

En este artículo, pude demostrar en la práctica el uso de 2 sugerencias de consulta ampliamente utilizadas por los desarrolladores para evitar bloqueos al leer datos, que son NOLOCK y READPAST, y demostrar efectivamente el efecto de estas sugerencias en una consulta.

La idea de escribir este artículo surgió de una pregunta enviada al grupo. “Servidor SQL – DBA”, de Telegram, y también unas viejas ganas de escribir sobre esto cada vez que veo entornos donde casi todas las consultas tienen NOLOCK.

Después de leer esta publicación, podrás entender exactamente cómo funcionan estos 2 consejos y los utilizarás sabiamente y sólo cuando sea conveniente. No es necesario poner NOLOCK/READPAST en todas tus consultas, ¡eh!

Si su entorno tiene mucha competencia y los bloqueos, bloqueos y puntos muertos son frecuentes y un problema para usted, le sugiero pensar en un enfoque más completo que usar estas sugerencias, que sería usar el modo de aislamiento de instantánea de lectura confirmada (RCSI), que le permite usar el modo de lectura confirmada sin bloquear las lecturas cuando ocurren transacciones abiertas. Como no todo es color de rosas, existen algunos efectos secundarios al utilizar este modo, como una posible caída del rendimiento. Si quieres saber más sobre él, te sugiero leer el artículo. Leer aislamiento de instantáneas confirmadas: escritores bloquean escritores (RCSI), del gran maestro Brent Ozar.

#5 – SQL Server – Cómo evitar y protegerse de ataques de ransomware, como WannaCry, en su servidor de base de datos

En el artículo número 350 de este blog, les compartí mi experiencia durante varias pruebas que realicé sobre Ransomware en servidores de bases de datos SQL Server, como WannaCry, que descargué e “infecté” mi VM solo para realizar estas pruebas, entender cómo actúa y cómo podemos protegernos contra este tipo de ataque que, por increíble que parezca, todavía es común en el día a día de los DBA que trabajan en empresas de consultoría.

Según el Internet Security Booklet, el ransomware es un tipo de código malicioso que vuelve inaccesibles los datos almacenados en el equipo, generalmente mediante cifrado, y que exige el pago de un rescate (rescate) para restablecer el acceso al usuario, donde el pago del rescate generalmente se realiza mediante bitcoins u otras criptomonedas.

El Ransomware más conocido hasta la fecha es WannaCry, el cual fue considerado el mayor ataque de este tipo jamás registrado hasta la fecha, comenzando el 12/05/2017, atacando alrededor de 150 países e infectando más de 230 mil sistemas, aunque hay varios otros ejecutándose en la red.

#4 – SQL Server – Consultas útiles de DBA del día a día que siempre hay que buscar en Internet

En este artículo, tuve el placer de poder compartir contigo varios scripts útiles para el día a día de DBA que siempre debes buscar en Internet cuando necesitas realizar una determinada consulta. Mi idea en este artículo era hacerte la vida más fácil y tener un artículo con varios scripts, para diferentes propósitos, para que los marques como favoritos en tu navegador y tengas siempre la información que deseas en un solo lugar.

#3 – SQL Server – Lista de verificación de seguridad – Un SP con más de 70 elementos de seguridad para validar su base de datos

En este artículo te compartí un proyecto que vengo desarrollando desde noviembre de 2018 y que hoy cuenta con más de 6,000 líneas de código, que es un Checklist de Seguridad muy completo (probablemente el más completo y completo que encontrarás en Internet), con más de 70 elementos de Seguridad para validar tu base de datos, incluyendo configuraciones y parámetros, permisos, objetos de programación ¡y mucho más!

Después de ver tantas empresas, desarrolladores (y a veces los propios DBA) descuidar el aspecto de seguridad, donde vemos entornos en los que la aplicación utiliza el usuario “sa”, encontramos miles de intentos de conexión con contraseñas incorrectas y nadie hace nada, entornos SIN BACKUP y muchos otros absurdos, decidimos crear una manera muy práctica y fácil de tener rápidamente una visión general de cómo está la seguridad de la instancia, en un formato amigable y con información técnica al mismo tiempo, y que permite exportar fácilmente a Excel y demostrar los diversos problemas al cliente. encontrados, el impacto que puede tener en el medio ambiente y cómo solucionarlo.

Descubra la solución definitiva a la gran mayoría de sus problemas de seguridad de SQL Server en este artículo.

#2 – Ley General de Protección de Datos Personales (LGPDP o LGPD) aplicada a las bases de datos SQL Server

En este artículo pude abordar un tema muy popular en el área de la tecnología en general, que es la Ley General de Protección de Datos Personales (LGPDP o LGPD), “prima” del GDPR que está vigente en Europa, y debería convertirse en realidad en Brasil a partir de agosto de 2020, trayendo varios cambios en la forma en que los profesionales de TI trabajan en su vida diaria y en la forma en que se desarrollan los productos (Software, bases de datos, etc.).

LGPD es el acrónimo de Ley General de Protección de Datos, cuyo objetivo es aumentar la privacidad de los datos personales y evitar casos como grandes filtraciones de información y escándalos que involucran precisamente el mal uso de la información personal que venimos siguiendo en los últimos años. La creación de esta ley coloca a Brasil en la lista de más de 100 países que, hoy, pueden considerarse adecuados para proteger la privacidad y el uso de datos en el escenario global.

A diferencia de todo lo que he leído sobre este tema, el objetivo al crear este artículo fue centrar este análisis específicamente en las bases de datos SQL Server, demostrando cómo podemos mejorar la seguridad de nuestra base de datos y cumplir con esta nueva ley.

#1 – SQL Server – Uso de columnas calculadas (o columnas calculadas) para ajuste del rendimiento

En este artículo me gustaría compartir con ustedes algo que veo mucho a diario cuando estoy realizando consultoría de Tuning, que son consultas que consumen mucho tiempo, con alto consumo de E/S y CPU, y que usan funciones WHERE o JOIN en tablas con muchos registros y cómo podemos usar una técnica de indexación de columnas calculada (o computada) muy simple para resolver este problema.

Como comento en el artículo. Comprender cómo funcionan los índices en SQL Server, al usar funciones en cláusulas WHERE o JOINS, estamos violando el concepto de SARGabilidad de la consulta, es decir, estamos provocando que esta consulta ya no utilice operaciones Seek en los índices, ya que SQL Server necesita leer la tabla completa, aplicar la función deseada y luego comparar los valores y devolver los resultados.

Lo que quiero en este artículo es mostrarle este escenario, cómo identificarlo y algunas posibles soluciones para mejorar el rendimiento de las consultas. Entonces, ¡vamos!

¡Buenos chicos!
Espero que hayas disfrutado de esta pequeña lista, un fuerte abrazo y ¡nos vemos en el próximo post!