Cura d; baze de date privind pierderea în greutate, ce dietă să alegeți

În acest articol vom aborda un subiect oh! cât de sensibil și mult prea des neglijat de editorii de pachete software și alte aplicații „de acasă” purjarea datelor.

Vă rugăm să rețineți că vorbim despre purjare, adică eradicarea totală a datelor și nu arhivarea, care este o tehnică complet diferită, deși complementară, dar guvernată de reguli foarte precise, care definesc un format complet diferit de cel al datelor de origine, independent de orice constrângere tehnică. Revenim însă la subiectul nostru preferat PURGE datele așa cum le-ați văzut adesea vedeți că scumpele dvs. baze de date cresc scandalos fără a exista o procedură sau un tratament care să ușureze aceste date care devin învechite în timp și la care nu se mai accesează nici în citire, nici în scris, ci pe de altă parte mână care poluează tabelele care riscă să degradeze foarte mult performanța. Așadar, o mică cură de slăbire nu ar fi un lux pentru a recâștiga o a doua tinerețe și a respecta canoanele de frumusețe care inundă unele dintre reviste, deși mă îndoiesc că o bază de date va declanșa o astfel de nebunie ... Efectul este mult mai puțin atractiv ...

Deci, la cine ne vom adresa pentru a găsi acest leac miraculos care ne va face să pierdem mai multe dimensiuni într-un timp minim? Dar, bineînțeles, față de nutriționistul de serviciu, dragul nostru DBA care ajunge să chicotească mai puțin în spatele ecranului său.

Analiza supraponderalității

Înainte de a diagnostica care dietă este cea mai eficientă, trebuie mai întâi să studiem natura supraponderalității cu care ne confruntăm și să definim ce date merită această dietă uscată. În general, avem deja o idee despre datele care cresc pe apă sau mai degrabă în timp, cum ar fi facturile, comenzile, consumul, biletele de comunicare, tranzacțiile financiare ... Rămâne acum să identificăm tabelele pe care sunt concentrate aceste date grosolane., da, dar apoi ce abordare să adopte:

Criteriul de slăbire

Deoarece acestea sunt date care se dezvoltă în timp, singurul criteriu relevant este, desigur, o dată care trebuie să corespundă în mod imperativ funcțional unui act semnificativ al cererii (preluarea comenzilor, consum, comunicare, tranzacție, facturare ...). Acum tot ce trebuie să faceți este să validați acest criteriu cu studiile sau cu managerii de aplicații și să determinați cu cât veți tăia acest volum în exces din date ... Cu alte cuvinte, într-un limbaj mai banal, „tăiați gras". Această perioadă de păstrare ne va permite să rafinăm și să dăm silueta bazei de date în conformitate cu dorințele noastre.

Dieta adecvată pentru slăbit

Acum trebuie doar să ne aplicăm tratamentul curativ în funcție de posibilitățile și mijloacele noastre.

Dieta drastică

Pentru mai bine și cu condiția să avem opțiunea de partiționare (care merită în continuare greutatea sa în arahide, apropo) și că, în plus pentru toate tabelele, din fericire aveți faimosul criteriu de dată, atunci soluția este găsită să utilizați opțiunea de partiționare pe intervale sau „partiționare în interval” .

Cu versiunea Oracle 11g, această opțiune a fost îmbunătățită, astfel încât nu mai este obligatoriu să creați partiții în prealabil, deoarece acestea sunt generate automat de îndată ce o nouă linie trebuie inserată într-o partiție care nu există încă.

Ca întotdeauna, există unele restricții în utilizarea acestui tip de partiționare pe intervale.

O singură coloană nu poate constitui criteriul de partiționare și această coloană trebuie să fie de tip DATE sau NUMĂR
Partiționarea la intervale nu este permisă pe tabelele organizate în indexuri IOT

Adâncimea intervalului de partiționare poate fi limitată la zi, săptămână, lună, trimestru…. prin următoarele funcții: INTERVAL (NUMTODSINTERVAL (1, 'zi')), INTERVAL (NUMTODSINTERVAL (7, 'zi')), INTERVAL (NUMTOYMINTERVAL (1, 'lună')), INTERVAL (NUMTOYMINTERVAL (3, 'lună') ))) ... . Deoarece numele partițiilor este generat automat în conformitate cu convențiile Oracle interne, se recomandă redenumirea acestora în conformitate cu propriile standarde.

Deci, cura de slăbire va fi efectuată prin simpla ștergere a partiției folosind comanda DROP, respectând, desigur, secvențierea constrângerilor referențiale. (mai întâi mesele fiice, apoi mesele mame).

O constrângere puternică a acestei comenzi DROP PARTITION rămâne faptul că toți indexurile sunt locale, adică se referă numai și direct la o singură partiție a tabelului, în caz contrar, indexurile vor fi invalidate și vor trebui reconstruite ceea ce necesită oprirea serviciului aplicației și afectează în continuare disponibilitatea bazei de date. Rămâne cazul spinos al indexurilor primare care se referă la întregul tabel, astfel încât acestea să devină locale, este imperativ să adăugați criteriul de partiționare în definiția cheie a acestor indici primari.