Partisi tabel untuk pengarsipan data

13

Skenario:

  • dua database: DB_A dan DB_Archive dengan satu tabel yang sangat besar yang disebut tableA.
  • setiap hari, catatan yang lebih lama dari 60 hari dihapus dari DB_A dan dipindahkan ke DB_Archive terutama untuk membiarkan hal "terpisah" karena tableA sangat ditanyakan pada DB_A untuk catatan 2 bulan terakhir.

Saya ingin menyingkirkan proses ini karena lambat dan menghabiskan banyak sumber daya. Saya berpikir untuk mengimplementasikan tabel partisi pada DB_A dengan fungsi partisi pada kolom tanggal dan menyimpan semua catatan <2 bulan pada satu partisi dan semua catatan> 2 bulan pada partisi lain. Pertanyaan saya:

  • Apakah skenario ini akan berperilaku seperti jika saya memiliki 2 database berbeda? Jika saya meminta tableA saya untuk catatan> getdate () - 30, apakah itu akan membaca partisi pengarsipan?
  • Saya kira saya harus mempartisi indeks juga, kan?
  • Bagaimana saya menangani kenyataan bahwa besok fungsi partisi saya akan "berubah", maksud saya, jika saya membuat fungsi hari ini (2 Juli, jangkauannya akan 2 Mei, tetapi besok akan menjadi 3 Mei). Bisakah saya membuat fungsi partisi dinamis?
sql-server  sql-server-2005  partitioning 
— Diego
sumber
Saya tidak berpikir fungsi dinamis adalah ide yang baik bahkan jika itu diizinkan (saya tidak berpikir itu adalah) ... kita bisa masuk ke detail lebih cepat tapi saya pikir Anda mungkin harus mempartisi berdasarkan tanggal kalender dan pindah satu partisi pada suatu waktu ... Tetapi ada berbagai opsi di sini.
— JNK
Saya membuat contoh sesuai dengan apa yang ingin Anda lakukan tahun lalu. Itu adalah kasus yang agak istimewa dimana kami ingin menyimpan x hari data pada larik cepat (mahal) dan memindahkan data arsip ke penyimpanan yang lebih murah. Jika saya bisa membersihkan contoh script saya akan mempostingnya, kalau tidak, itu hanya ringkasan proses.
— Mark Storey-Smith
hai tandai, ya silakan lakukan, dan jika Anda dapat berbagi pengalaman Anda juga. apakah itu berhasil?
— Diego
Ini bekerja tetapi pada akhirnya tidak perlu (kami mengambil rute yang lebih sederhana). Mungkin Anda bisa memperluas mengapa batas 60 hari ada dalam kasus Anda? Akan membantu semua orang mengarahkan Anda ke arah yang benar.
— Mark Storey-Smith

Jawaban:

6

Dengan mempartisi, Anda harus melakukan partisi per hari, yang menempatkan batas Pra-SQL 2012 1000 partisi dalam perspektif baru karena hanya akan memungkinkan arsip 3 tahun. Dengan SQL Server 2012 Anda mendapatkan 15000 partisi yang banyak untuk 1 partisi per hari.

Setiap hari Anda akan menambahkan partisi baru. Jika Anda ingin memindahkan partisi 61 hari yang lalu, Anda dapat melakukannya secara efisien, tetapi masih merupakan operasi offline. Lihat Memindahkan Partisi ke Grup File Lain secara Efisien .

Semua indeks Anda harus disejajarkan, lihat Pedoman Khusus untuk Indeks yang Dipartisi .

Membeli ke dalam partisi bukanlah keputusan yang mudah dan mungkin cukup banyak untuk dikunyah ... lihat Cara Memutuskan apakah Anda Harus Menggunakan Partisi Tabel . Khususnya Anda tidak boleh mengharapkan peningkatan kinerja dari partisi. Anda harus mendekati masalah kinerja tepat waktu dengan mengelompokkan berdasarkan waktu.

— Remus Rusanu
sumber
Batas baru tersedia di 2008 SP2 dan 2008 R2 SP1. blogs.msdn.com/b/hanspo/archive/2010/11/29/…
— Jon Seigel
@ Jon: implementasi SP1 2008, 2008R2 SP1 hadir dengan peringatan besar . As explained in this white paper, there are implications on certain features, including performance. . Dukungan SQL 2012 datang tanpa peringatan.
— Remus Rusanu
Terima kasih telah menunjukkannya; memang benar ada beberapa peringatan untuk menggunakannya pada 2008/2008 R2, tetapi ini merupakan opsi yang tersedia jika perlu.
— Jon Seigel
terima kasih atas komentar Anda. Saya akan membaca komentar materi nanti
— Diego
2

Saya tidak tahu apakah fungsi partisi bisa dinamis tetapi saya ragu. Beberapa opsi untuk Anda tanpa menempuh rute itu:

1 - Partisi di kalender DATE dan pindah dari partisi tertua setiap hari

2 - Buat tampilan yang memfilter pada tanggal, dan arahkan semua pertanyaan Anda yang ada di sana (ini dapat dengan mudah dikelola dengan mengubah nama tabel yang mendasari ke sesuatu yang lain dan memberi nama tampilan apa nama tabel saat ini). Ini dapat dioptimalkan juga dengan perubahan indeks.

Ingatlah bahwa opsi pertama di atas akan bekerja BANYAK lebih baik jika Anda menggunakan bidang tanggal di kueri Anda. Jika tidak, itu masih akan lebih cepat dari proses saat ini tetapi permintaan tidak akan mengalami peningkatan besar. Partisi secara umum berfungsi paling baik jika Anda dapat memfilter pada bidang partisi Anda dan pengoptimal tahu partisi mana yang harus dilihat.

— JNK
sumber
Saya ingin menghindari operasi manual "setiap hari"
— Diego
2

Inilah yang harus bekerja untuk Anda: DB_A - tableA dengan partisi berbeda untuk masing-masing 60 hari terakhir - stagingTable untuk memindahkan data dari partisi tertua

DB_Archive tableA - menyimpan semua data yang lebih lama dari 60 hari. (tidak dipartisi)

Proses: 1. sebelum akhir hari: ubah fungsi partisi - rentang split untuk menambahkan partisi baru untuk hari baru. (NB: alih-alih membuat partisi untuk "hari ini + 1 hari" Anda mungkin ingin menjadi beberapa langkah di depan. Misalnya: "hari ini + 5 hari"

  1. Setelah akhir setiap hari, Anda pertama kali beralih partisi tertua di DB_A.tableA ke DB_A.stagingTable; Gabungkan partisi tertua.

  2. Impor data dari DB_A.stagingTable ke DB_Archive.tableA. Akhirnya trunacte DB_A.stagingTable

Di atas disebut Rolling Window dan merupakan skenario yang cukup umum untuk VLDB. Lihat buku putih ini oleh microsoft pada partisi: Tabel partisi dan strategi indeks atau coba ini secara khusus pada skenario Jendela Geser

— Dharmendar Kumar 'DK'
sumber
Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.