Buna ziua

As dori sa aflu cum se abordeaza o situatie in care ai o tabela cu foarte multe inregistrai, care ajunge sa nu mai incapa pe un singur hard-disk local.

1. folosind "partitionare", nu afeacteaza back-up-ul, search-ul care ar fii cea mai bun mod de partitionare

2. folosind un sistem de mai multe tabela (exemplu toate inregistrarile din mai  - o tabela, iunie - o tabela ....)

 

Va multumesc

Petre

Personal va recomand partitionarea.

---

Cristian Andrei Lefter, SQL Server MVP
MCT, MCSA, MCDBA, MCAD, MCSD .NET,
MCTS, MCITP - Database Administrator SQL Server 2005
http://sqlserver.ro

Syberye:

1. folosind "partitionare", nu afeacteaza back-up-ul, search-ul care ar fii cea mai bun mod de partitionare

2. folosind un sistem de mai multe tabela (exemplu toate inregistrarile din mai  - o tabela, iunie - o tabela ....)

Depinde cite date ai si cum faci regasirea datelor.
Raspunsul lui Cristian e bun -  totusi, daca vrei date anuale_lunare si ai mili(oane)(arde) de inregistrari, optiunea 2 s-ar putea dovedi cistigatoare

---

Ignat Andrei
http://serviciipeweb.ro/iafblog

Eu aş sugera să evaluaţi şi soluţii bazate pe striping (RAID-0), adică să faceţi din mai multe discuri fizice un singur disc logic.

Citat din Designing Partitions to Improve Query Performance:
"It may be tempting to map your partitions to filegroups, each accessing a different physical disk drive, in order to improve I/O performance. When SQL Server performs data sorting for I/O operations, it sorts the data first by partition. Under this scenario, SQL Server accesses one drive at a time, and this might reduce performance. A better solution in terms of performance is to stripe the data files of your partitions across more than one disk by setting up a RAID. In this way, although SQL Server still sorts data by partition, it can access all the drives of each partition at the same time. "

Răzvan

Salut.

Evident, partitionarea e "the way to go"; problema e ca ai nevoie, intr-adevar, de un disk subsystem decent. Din datele pe care le expui se pare ca e un pic mai complexa problema in cazul tau (adica nu ai resurse pentru SANs, RAID arrays, etc. daca ai, mea culpa).
Am o singura intrebare: se pot sterge sau arhiva datele istorice din tabela sau trebuie sa ramana tabela asa cum e?

toate cele bune,
calin

Sistemul trebe sa pastreze inregistrarile 10 ani - astfel incit sa poata fii regasite cu usurinta. Resurse fizice din cite am inteles sint destule.

Cu respect,

Petre

 

 

OK, atunci e clar ca ai nevoie de partitionare.

Ca sa fim cinstiti cu definitiile, spargerea unei tabele mai mari in tabele mai mici e tot partitionare, "horizontal" partitioning, dar atunci trebuie sa fie un view peste acele tabele, ceea ce complica un pic lucrurile (la SELECT ai UNION ALL, in plus trebuie sa aplici tot felul de constrainturi de validare, etc).

Lasand la o parte partea teoretica, iti recomand cu cea mai mare caldura un articol scris de Kimberly Tripp http://msdn.microsoft.com/en-us/library/ms345146(SQL.90).aspx. Pentru un tutorial destul de bine facut, http://blog.sqlauthority.com/2008/01/25/sql-server-2005-database-table-partitioning-tutorial-how-to-horizontal-partition-database-table/.

toate cele bune,
calin

Daca problema este principala spatiul pe disk nu trebuie nimic special, pur si simplu mai adaugi un fisier NDF la filegroup-ul pe care se afla tabela (probabil PRIMARY), pe un nou disk:

ALTER DATABASE <dbname> ADD FILE (name=<logicalfilename>, file='<fiisierpenouldisk.ndf', size=<spatiu folosibilpenouldisk>) TO PRIMARY;

Baza de date, si implicit tabela problema, se va 'extinde' automat pe noul fisier si va putea sa creasca cit are loc pe noul disk. Asta e o solutie rapida, cu risk minim si care nu afecteaza design-ul logic ala bazei de date in nici un fel. Fisierele de backup vor creste corespunzator ca marime.

O solutie mai complexa este sa folosesti partitionare, dar asta trebuie sa vorbesti cu un profesionist sa te ajute, daca o face un amator mai mult strica. Cit despre mai multe tabele, sint nenumarate dezavantaje, in principal legat de accesul la tabele din aplicatie si rapoarte.

O alta solutie extrem de eficienta si cu risk foarte redus este sa treci pe SQ 2008 si sa folosesti PAGE COMPRESSION. In general se obtine un raport de compresie de 40-60%, cu imbunatatiri imediate in viteza aplicatiei (mai putin IO) si cu eliberarea spatiului compresat pentru mai multe date.

---

http://rusanu.com

Va multumesc din suflet domnilor

Petre