Partizionamento delle tabelle per l'archiviazione dei dati

Scenario:

• due database: DB_A e DB_Archive con una tabella molto grande chiamata tableA.
• ogni giorno, i record più vecchi di 60 giorni vengono eliminati da DB_A e spostati in DB_Archive principalmente per lasciare la cosa "separata" perché la tabella A è fortemente interrogata su DB_A per i record degli ultimi 2 mesi.

Voglio sbarazzarmi di questo processo perché è lento e consuma molte risorse. Sto pensando di implementare il partizionamento delle tabelle su DB_A con una funzione di partizione su una colonna data e di archiviare tutti i record <2 mesi su una partizione e tutti i record> 2 mesi su un'altra partizione. Le mie domande:

• questo scenario si comporterà come se avessi 2 database diversi? Se eseguo una query sulla mia tabella A per i record> getdate () - 30, leggerà la partizione di archiviazione?
• Suppongo di dover anche partizionare gli indici, giusto?
• Come posso affrontare il fatto che domani la mia funzione di partizione "cambierà", intendo, se creo la funzione oggi (2 luglio, il suo intervallo sarà il 2 maggio, ma domani sarebbe il 3 maggio). Posso creare una funzione di partizione dinamica?

Con il partizionamento dovresti fare una partizione al giorno, che pone il limite pre-SQL 2012 di 1000 partizioni in una nuova prospettiva poiché consentirebbe solo un archivio di 3 anni. Con SQL Server 2012 ottieni 15000 partizioni che sono sufficienti per 1 partizione al giorno.

Ogni giorno aggiungi una nuova partizione. Se vuoi spostare la partizione del 61 ° giorno passato puoi farlo in modo efficiente, ma è comunque un'operazione offline. Vedi Sposta una partizione in un altro gruppo di file in modo efficiente .

Tutti gli indici dovrebbero essere allineati, consultare le Linee guida speciali per gli indici partizionati .

Acquistare nel partizionamento non è una decisione facile e potrebbe essere un grosso morso da masticare ... vedi Come decidere se utilizzare il partizionamento della tabella . In particolare, non dovresti aspettarti miglioramenti delle prestazioni dal partizionamento. Dovresti affrontare i problemi di prestazioni nei tempi più seri raggruppando per datetime.

Non so se la funzione di partizione può essere dinamica ma ne dubito. Alcune opzioni per te senza seguire quel percorso:

1 - Partizione sul calendario DATA e spostare ogni giorno la partizione più vecchia

2 - Crea una vista che filtra alla data e punta lì tutte le tue query esistenti (questo può essere facilmente gestito rinominando la tabella sottostante in qualcos'altro e nominando la vista come si chiama la tabella corrente). Questo può essere ottimizzato anche con le modifiche dell'indice.

Tieni presente che la prima opzione sopra funzionerà MOLTO meglio se usi il campo data nelle tue query. In caso contrario, sarà ancora più veloce del processo corrente, ma le query non avranno un enorme miglioramento. Il partizionamento in generale funziona meglio se è possibile filtrare sul campo di partizione e l'ottimizzatore sa quale partizione guardare.

Ecco cosa dovrebbe funzionare per te: DB_A - tableA con una partizione diversa per ciascuno degli ultimi 60 giorni - stagingTable per spostare i dati dalla partizione più vecchia

DB_Archive tableA - memorizza tutti i dati più vecchi di 60 giorni. (non partizionato)

Processo: 1. prima della fine della giornata: modifica della funzione di partizione - dividi l'intervallo per aggiungere una nuova partizione per il nuovo giorno. (NB: invece di creare partizioni per "data odierna + 1 giorno" potresti voler fare qualche passo avanti, ad es. "Data odierna + 5 giorni"

1. Dopo la fine di ogni giorno, si passa prima alla partizione più vecchia in DB_A.tableA in DB_A.stagingTable; Unisci le partizioni più vecchie.

2. Importare dati da DB_A.stagingTable a DB_Archive.tableA. Finalmente trunacte DB_A.stagingTable

Quanto sopra si chiama Rolling Window ed è uno scenario abbastanza comune per i VLDB. Vedi questo white paper di Microsoft sul partizionamento: tabella delle partizioni e strategie di indice o prova questo nello scenario Finestra scorrevole

È possibile utilizzare l'approccio dinamico di archiviazione ed eliminazione dei dati in SQL Server. Si prega di seguire il link qui sotto per quello.

http://www.sqlscientist.com/2012/09/auto-maintain-archival-process.html