<?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/it/tags/partitioning/</link><description>Recent content in Partitioning on Ivan Luminaria</description><generator>Hugo</generator><language>it</language><lastBuildDate>Tue, 23 Dec 2025 08:03:00 +0100</lastBuildDate><atom:link href="https://ivanluminaria.com/it/tags/partitioning/index.xml" rel="self" type="application/rss+xml"/><item><title>Oracle Partitioning: quando 2 miliardi di righe non entrano più in una query</title><link>https://ivanluminaria.com/it/posts/oracle/oracle-partitioning/</link><pubDate>Tue, 23 Dec 2025 08:03:00 +0100</pubDate><guid>https://ivanluminaria.com/it/posts/oracle/oracle-partitioning/</guid><description>&lt;p&gt;Due miliardi di righe. Non è un numero che si raggiunge in un giorno. Ci vogliono anni di transazioni, di movimenti, di registrazioni quotidiane che si accumulano. E per tutto quel tempo il database funziona, le query rispondono, i report escono. Poi un giorno qualcuno apre un ticket: &amp;ldquo;il report mensile ci mette quattro ore.&amp;rdquo;&lt;/p&gt;
&lt;p&gt;Quattro ore. Per un report che sei mesi prima ne impiegava venti minuti.&lt;/p&gt;
&lt;p&gt;Non è un bug. Non è un problema di rete o di storage lento. È la fisica dei dati: quando una tabella cresce oltre una certa soglia, gli approcci che funzionavano smettono di funzionare. E se non hai progettato la struttura per gestire quella crescita, il database fa l&amp;rsquo;unica cosa che può fare: leggere tutto.&lt;/p&gt;</description></item></channel></rss>