<?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/ro/tags/partitioning/</link><description>Recent content in Partitioning on Ivan Luminaria</description><generator>Hugo</generator><language>ro</language><lastBuildDate>Tue, 23 Dec 2025 08:03:00 +0100</lastBuildDate><atom:link href="https://ivanluminaria.com/ro/tags/partitioning/index.xml" rel="self" type="application/rss+xml"/><item><title>Oracle Partitioning: când 2 miliarde de rânduri nu mai încap într-o interogare</title><link>https://ivanluminaria.com/ro/posts/oracle/oracle-partitioning/</link><pubDate>Tue, 23 Dec 2025 08:03:00 +0100</pubDate><guid>https://ivanluminaria.com/ro/posts/oracle/oracle-partitioning/</guid><description>&lt;p&gt;Două miliarde de rânduri. Nu este un număr la care ajungi într-o zi. Durează ani de tranzacții, mișcări, înregistrări zilnice care se acumulează. Și în tot acest timp baza de date funcționează, interogările răspund, rapoartele ies. Apoi într-o zi cineva deschide un ticket: „raportul lunar durează patru ore.&amp;quot;&lt;/p&gt;
&lt;p&gt;Patru ore. Pentru un raport care cu șase luni înainte dura douăzeci de minute.&lt;/p&gt;
&lt;p&gt;Nu este un bug. Nu este o problemă de rețea sau de stocare lentă. Este fizica datelor: când o tabelă crește peste un anumit prag, abordările care funcționau nu mai funcționează. Și dacă nu ai proiectat structura să gestioneze acea creștere, baza de date face singurul lucru pe care îl poate face: citește totul.&lt;/p&gt;</description></item></channel></rss>