Roberto Carrancio

En la era de los datos, no gana quien tiene más información. Gana quien la encuentra más rápido.

Fíjate en esto.

Un servidor nuevo. Discos SSD. 128 GB de RAM. 12 núcleos. Y las consultas siguen tardando una eternidad.

El departamento pide informes. Tú lanzas la query. Y te quedas mirando cómo pasan los segundos. Los minutos. Mientras la ruedita gira y tu credibilidad se desinfla.

¿Te suena?

Porque el problema no es el hardware. Nunca lo fue.

A principios del siglo XX, la carrera por lograr el vuelo tripulado tenía un claro favorito: Samuel Langley. Secretario del Smithsonian, con financiación del gobierno, los mejores ingenieros y los motores más potentes disponibles. Todo el mundo apostaba por él.

Mientras tanto, dos mecánicos de bicicletas de Ohio —Wilbur y Orville Wright— apenas tenían dinero. Lo que sí tenían era algo que Langley no: construyeron un pequeño túnel de viento en su taller y pasaron meses estudiando cómo se comportaba el aire al pasar sobre una superficie. Probaron más de 200 formas de ala. Entendieron las fuerzas invisibles que hacían posible el vuelo.

La estrategia de Langley: más potencia, motores más grandes. La de los Wright: entender qué pasa por dentro.

El 17 de diciembre de 1903, los hermanos Wright volaron en Kitty Hawk. La máquina de Langley se había estrellado en el río Potomac nueve días antes.

Ganaron los que tenían menos recursos. Porque entendieron lo que ocurría debajo del capó.

Con tu servidor de base de datos pasa exactamente lo mismo. Puedes comprar más RAM, más núcleos, discos más rápidos. Pero si no entiendes cómo SQL Server procesa las consultas por dentro —cómo organiza los datos en páginas, cómo decide qué índice usar, cómo gestiona los bloqueos entre procesos— estás haciendo lo mismo que Langley: meter más potencia esperando que el problema se resuelva solo. Y no se resuelve.

Sé de lo que hablo

Roberto Carrancio lleva más de una década trabajando con SQL Server. Empezó como DBA y se ha especializado en lo que pocos dominan: rendimiento.

Actualmente es Ingeniero de Rendimiento de SQL Server en IESA, la empresa detrás de la aplicación Tu Comunidad. Ha tenido la oportunidad de trabajar con empresas de todos los tamaños y de todos los sectores —algo que le da una visión que muy pocos profesionales pueden ofrecer.

Ha publicado más de 200 artículos técnicos en su blog, tiene un curso completo de Transact-SQL en su canal de YouTube y lidera una comunidad de más de 260 profesionales de SQL Server en Telegram. Todo esto en poco más de un año de actividad pública.

En esta clase no da teoría de manual. Abre SQL Server Management Studio, escribe código en vivo, ejecuta demos delante de ti y te muestra exactamente qué pasa por dentro cuando lanzas una consulta.

Esto es lo que vas a aprender:

  • Por qué usar NOLOCK en tus consultas puede hacer que leas datos que nunca han existido en tu base de datos —Roberto lo demuestra en directo con una demo que deja a toda la sala en silencio.
  • Cómo leer los planes de ejecución de SQL Server para detectar en segundos qué consulta exacta está arruinando el rendimiento de tu servidor —y cómo encontrar los índices que te faltan.
  • La razón real por la que tu servidor va lento aunque tenga hardware de última generación (pista: no es culpa del hierro, es culpa de cómo SQL busca tus datos).
  • El error que cometen la mayoría de profesionales con los índices —crean demasiados pensando que "más es mejor"— y cómo eso multiplica los tiempos de escritura sin que se den cuenta.
  • Cómo los índices columnstore —la misma tecnología que usa Power BI internamente— pueden reducir las lecturas de disco de miles de páginas a un solo segmento. Lo verás medido con números reales.
  • La técnica de aislamiento que usan Oracle y Azure SQL Database para eliminar bloqueos entre lectores y escritores sin comprometer la integridad de tus datos —y cómo activarla en tu SQL Server.
  • La analogía del melocotón: la explicación más clara que vas a escuchar jamás sobre cómo SQL Server procesa internamente tus consultas (FROM, WHERE, SELECT) y por qué entenderlo cambia tu forma de escribir código.

ATENCIÓN, HAY ALGO QUE NO TE ESPERAS

En un momento de la clase, Roberto prepara una demo que deja a toda la sala en silencio.

Crea una tabla con 10.000 registros. Lanza un proceso que actualiza datos y otro que los cuenta simultáneamente usando NOLOCK. Resultado: SQL Server cuenta 9.966. Luego 9.989. Después 10.175. En una tabla que siempre tiene exactamente 10.000 filas.

Pero no se queda ahí. En una segunda demo todavía más reveladora, demuestra que NOLOCK puede leer un campo que empieza con un valor y termina con otro completamente distinto. Datos corruptos. En milisegundos.

Si alguna vez has puesto NOLOCK en una consulta "porque va más rápido", esta demo sola justifica cada minuto invertido en esta clase.

Qué incluye:

Grabación completa de la clase (más de 3 horas de contenido), scripts SQL de todas las demos ejecutadas en vivo y las diapositivas de la presentación.


Nos vemos dentro.