<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>Partitioning on Ivan Luminaria</title><link>https://ivanluminaria.com/es/tags/partitioning/</link><description>Recent content in Partitioning on Ivan Luminaria</description><generator>Hugo</generator><language>es</language><lastBuildDate>Tue, 23 Dec 2025 08:03:00 +0100</lastBuildDate><atom:link href="https://ivanluminaria.com/es/tags/partitioning/index.xml" rel="self" type="application/rss+xml"/><item><title>Oracle Partitioning: cuando 2 mil millones de filas ya no caben en una query</title><link>https://ivanluminaria.com/es/posts/oracle/oracle-partitioning/</link><pubDate>Tue, 23 Dec 2025 08:03:00 +0100</pubDate><guid>https://ivanluminaria.com/es/posts/oracle/oracle-partitioning/</guid><description>&lt;p&gt;Dos mil millones de filas. No es un número que se alcance en un día. Se necesitan años de transacciones, movimientos, registros diarios que se acumulan. Y durante todo ese tiempo la base de datos funciona, las consultas responden, los reportes salen. Luego un día alguien abre un ticket: &amp;ldquo;el reporte mensual tarda cuatro horas.&amp;rdquo;&lt;/p&gt;
&lt;p&gt;Cuatro horas. Para un reporte que seis meses antes tardaba veinte minutos.&lt;/p&gt;
&lt;p&gt;No es un bug. No es un problema de red o de almacenamiento lento. Es la física de los datos: cuando una tabla crece más allá de cierto umbral, los enfoques que funcionaban dejan de funcionar. Y si no diseñaste la estructura para manejar ese crecimiento, la base de datos hace lo único que puede: leerlo todo.&lt;/p&gt;</description></item></channel></rss>