Anda sedang offline saat ini, menunggu internet Anda untuk menyambung kembali

Deskripsi log dan data penyimpanan algoritma yang memperbesar kehandalan data di SQL Server

PENTING: Artikel ini diterjemahkan oleh perangkat lunak penerjemahan mesin Microsoft, dan mungkin telah diedit oleh Masyarakat Microsoft melalui teknologi CTF dan bukan oleh seorang penerjemah profesional. Microsoft menawarkan baik artikel yang diterjemahkan oleh manusia maupun artikel hasil editan terjemahan oleh mesin/komunitas, sehingga Anda dapat mengakses semua artikel di Sentra Pengetahuan yang kami miliki dalam berbagai bahasa. Namun artikel hasil editan mesin atau bahkan komunitas tidak selalu sempurna. Artikel ini dapat mengandung kesalahan dalam hal kosa kata, sintaksis atau tatabahasa, sangat mirip dengan penutur asing yang membuat kekeliruan ketika berbicara dalam bahasa Anda. Microsoft tidak bertanggung jawab atas ketidakakuratan, kesalahan atau kerugian apa pun akibat dari kekeliruan dalam penerjemahan isi atau penggunaannya oleh pelanggan kami. Microsoft juga akan senantiasa memperbarui perangkat lunak penerjemahan mesin dan alat untuk menyempurnakan Editan Hasil Penerjemahan Mesin.

Klik disini untuk melihat versi Inggris dari artikel ini: 230785
Ringkasan
Artikel ini membahas bagaimana Microsoft SQL Server log dan data algoritma memperpanjang data keandalan dan integritas.

Untuk mempelajari selengkapnya tentang konsep dasar mesin dan ARIES (algoritma untuk pemulihan dan isolasi pemanfaatan semantik), lihat transaksi ACM berikut di sistem Database kumpulan dokumen (di bawah "Volume 17, nomor 1, Maret 1992):

Penulis utama dari kumpulan dokumen ini adalah C. Mohan. kumpulan dokumen alamat penyuratan teknik SQL Server untuk memperluas data keandalan dan integritas yang terkait dengan kegagalan.

Kami sarankan Anda membaca artikel berikut di Pangkalan Pengetahuan Microsoft untuk informasi selengkapnya tentang tembolok dan diskusi mode kegagalan alternatif:
86903 Deskripsi caching kontroler disk di SQL Server
234656 Informasi tentang cara menggunakan kandar cache dengan SQL Server yang setiap database administrator harus tahu
Informasi lebih lanjut
Sebelum kita mulai diskusi mendalam, beberapa istilah yang digunakan di seluruh artikel ini ditetapkan di dalam Daftar Tabel berikut.
IstilahDefinisi
Cadangan usia bateraiLokal dan terpisah usia baterai cadangan fasilitas secara langsung tersedia dan dikontrol oleh mekanisme cache untuk menghindari kehilangan data.
Catatan Ini bukan uninterruptible power supply (UPS). UPS tidak menjamin aktivitas menulis dan dapat terputus dari peranti penangkap cache.
CacheMekanisme perantara penyimpanan yang digunakan untuk mengoptimalkan operasi I/O fisik dan meningkatkan kinerja.
Kotor HalamanHalaman yang berisi modifikasi data yang belum dihapus untuk penyimpanan stabil. Untuk informasi lebih lanjut tentang buffer kotor halaman, lihat "Menulis Halaman"topik di buku daring SQL Server.
Catatan Konten juga berlaku untuk Microsoft SQL Server 2012 dan versi yang lebih baru.
KegagalanApa pun yang mungkin menyebabkan gangguan yang tak terduga dari proses SQL Server. Contoh: daya pemutusan, reset komputer, galat kehabisan memori, lainnya masalah peranti penangkap keras, sektor yang rusak, kandar pemutusan, kegagalan sistem, dan sebagainya.
HapusMemaksa buffer tembolok untuk penyimpanan yang stabil.
KaitSinkronisasi objek yang digunakan untuk melindungi fisik konsistensi sumber daya.
Penyimpanan usia bateraiMedia yang tetap tersedia melalui kegagalan sistem.
Halaman disematkanHalaman yang tetap dalam data cache dan tidak dapat dihapus untuk penyimpanan stabil sampai semua data log terkait aman di lokasi penyimpanan stabil.
Stabil PenyimpananSama dengan usia baterai penyimpanan.
Penyimpanan tidak stabilMedia yang tidak akan tetap utuh seluruh kegagalan.

Protokol tulis-depan pengelogan (WAL)

Protokol istilah adalah cara yang hebat untuk menggambarkan WAL. Tertentu dan ditetapkan seperangkat implementasi langkah-langkah yang diperlukan untuk memastikan bahwa data yang disimpan dan ditukar dengan benar dan dapat dipulihkan ke keadaan diketahui jika terjadi kegagalan. Hanya jaringan berisi protokol yang ditetapkan untuk pertukaran data secara konsisten dan dilindungi, jadi terlalu WAL menjelaskan protokol untuk melindungi data.

kumpulan dokumen ARIES mendefinisikan WAL sebagai berikut:
Protokol WAL menegaskan bahwa data log mewakili perubahan ke beberapa data sudah harus stabil penyimpanan sebelum mengubah data diizinkan untuk mengganti versi sebelumnya data di penyimpanan usia baterai. Yaitu, sistem tidak diizinkan untuk menulis halaman diperbarui ke versi usia baterai penyimpanan halaman sampai setidaknya porsi Urungkan catatan log yang menjelaskan pemutakhiran untuk halaman yang telah ditulis ke stabil penyimpanan.
Untuk informasi lebih lanjut tentang pengelogan tulis-depan, lihat Log transaksi tulis-depan topik di buku daring SQL Server.

SQL Server dan WAL

SQL Server menggunakan protokol WAL. Untuk memastikan bahwa transaksi dengan benar berkomitmen, semua data log yang berkaitan dengan transaksi harus diamankan di penyimpanan stabil.

Untuk mengklarifikasi situasi ini, pertimbangkan contoh berikut ini.

Catatan Untuk contoh ini, menganggap bahwa ada indeks dan halaman yang terpengaruh adalah halaman 150.
BEGIN TRANSACTION   INSERT INTO tblTest VALUES (1)COMMIT TRANSACTION				
Berikutnya, membagi aktivitas ke langkah-langkah sederhana pengelogan, seperti yang dijelaskan di dalam Daftar Tabel berikut.
PernyataanTindakan yang dilakukan
MULAI TRANSAKSIDitulis ke log cache area. Namun, tidak diperlukan untuk Bersihkan untuk penyimpanan stabil karena SQL Server tidak membuat perubahan fisik.
MASUKKAN ke tblTest
  1. Data halaman 150 diakses ke SQL Server data tembolok, jika tidak telah tersedia.
  2. Halaman terkunci, disematkan, dan ditandai kotor, dan bukti kunci sesuai yang diperoleh.
  3. Rekaman masukkan Log dibuat dan ditambahkan ke log cache.
  4. Baris baru ditambahkan ke halaman data.
  5. Kait dirilis.
  6. Catatan log yang berkaitan dengan transaksi atau halaman tidak harus dihapus pada titik ini karena semua perubahan tetap berada di penyimpanan tidak stabil.
MELAKUKAN TRANSAKSI
  1. Catatan melakukan Log dibentuk dan data log yang berkaitan dengan transaksi harus ditulis ke stabil penyimpanan. Transaksi tidak dianggap berkomitmen hingga catatan log dengan benar ditetapkan ke penyimpanan stabil.
  2. Data halaman 150 tetap ada di cache data SQL Server dan tidak segera dihapus untuk penyimpanan stabil. Apabila data log dengan benar diamankan, pemulihan dapat mengulang operasi, bila perlu.
  3. bukti kunci transaksional dirilis.
Tidak bingung oleh syarat "mengunci" dan "pengelogan." Meskipun penting, penguncian dan pencatatan yang terpisah masalah ketika Anda menangani WAL. Dalam contoh sebelumnya, SQL Server umumnya memegang kait halaman 150 untuk waktu yang diperlukan untuk melakukan perubahan fisik sisipkan di halaman, bukan seluruh waktu transaksi. Ketik sesuai bukti kunci dibuat untuk melindungi baris, kisaran, halaman, atau Daftar Tabel yang diperlukan. Rujuk ke bagian penguncian buku daring SQL Server untuk rincian lebih lanjut tentang jenis bukti kunci.

Melihat contoh secara lebih rinci, Anda dapat meminta apa yang terjadi saat menjalankan proses LazyWriter atau pemeriksaan. SQL Server 7 masalah semua gejolak yang sesuai ke penyimpanan catatan log transaksi yang berkaitan dengan halaman kotor dan menyematkan stabil. Hal ini memastikan bahwa WAL protokol data halaman tidak dapat ditulis ke stabil penyimpanan hingga catatan log transaksi yang terkait telah dihapus.

SQL Server dan stabil Penyimpanan

SQL Server meningkatkan operasi halaman log dan data dengan termasuk pengetahuan ukuran sektor disk (biasanya 4,096 atau 512 bytes).

Untuk menjaga properti asam transaksi, SQL Server harus account poin kegagalan. Selama kegagalan banyak kandar cakram spesifikasi hanya menjamin sejumlah terbatas sektor menulis operasi. Sebagian besar spesifikasi menjamin penyelesaian menulis sektor tunggal ketika terjadi kegagalan.

SQL Server menggunakan halaman 8-KB data dan log (jika dihapus) pada kelipatan ukuran sektor. (Sebagian besar kandar cakram menggunakan 512 bita sebagai ukuran sektor default.) Dalam hal kegagalan, SQL Server dapat account untuk menulis operasi lebih besar daripada sektor dengan menggunakan log paritas dan teknik robek tulis.

Deteksi robek Halaman

Opsi ini memungkinkan SQL Server untuk mendeteksi lengkap pengoperasian I/O yang disebabkan oleh kegagalan daya atau pemutusan sistem lainnya. Ketika benar, hal ini menyebabkan sedikit dibalikkan untuk masing-masing sektor 512 bita 8-Kilobita (KB) database halaman setiap kali halaman ditulis ke disk. Jika sedikit dalam keadaan salah ketika halaman kemudian dibaca oleh SQL Server, maka halaman ditulis dengan benar; Halaman robek terdeteksi. Halaman robek biasanya terdeteksi selama pemulihan karena semua halaman yang ditulis secara tidak benar mungkin dapat dibaca oleh pemulihan.

Meskipun halaman pangkalan data SQL Server 8 KB, disk melakukan operasi I/O menggunakan sektor 512 bita. Oleh karena itu, sektor 16 ditulis per halaman pangkalan data. Halaman robek dapat terjadi jika sistem gagal (misalnya, karena kegagalan daya) antara waktu yang sistem operasi menulis sektor 512 bita pertama untuk disk dan menyelesaikan operasi I/O 8-KB. Jika sektor pertama halaman database berhasil ditulis sebelum kegagalan, halaman pangkalan data pada disk akan muncul sebagai diperbarui, walaupun ini mungkin tidak berhasil.

Dengan menggunakan disk cadangan usia baterai pengendali cache, Anda dapat memastikan bahwa data berhasil ditulis ke disk atau tidak ditulis sama sekali. Dalam situasi ini, tidak ditetapkan halaman robek deteksi ke "true" karena hal ini tidak diperlukan.

Catatan Deteksi robek halaman tidak diaktifkan secara asali di SQL Server. Untuk informasi selengkapnya, lihat website MSDN berikut:

Paritas log

Log parity Check ini sangat mirip dengan deteksi robek halaman. Masing-masing sektor 512 bita berisi parity bit. Bit paritas ini selalu ditulis dengan catatan log dan dievaluasi ketika catatan log diperoleh. Dengan memaksa log penulisan batas 512 bita, SQL Server dapat memastikan bahwa operasi berkomitmen sepenuhnya ditulis ke sektor fisik cakram.

Versi SQL Server yang lebih lama daripada 7.0

Versi SQL Server yang lebih lama daripada 7.0 tidak memberikan log paritas atau robek bit deteksi fasilitas. Pada kenyataannya, versi tersebut dapat menulis log halaman yang sama berkali-kali hingga catatan log isi halaman 2-KB log. Hal ini dapat membuka transaksi yang telah berhasil dilakukan. Jika halaman log ulang selama kegagalan, sektor dengan transaksi berkomitmen mungkin tidak mendapatkan ditulis ulang dengan benar.

Kinerja dampak

Semua versi SQL Server membuka berkas log dan data dengan menggunakan fungsi Win32CreateFile . Anggota dwFlagsAndAttributes menyertakan opsi FILE_FLAG_WRITE_THROUGHketika mereka dibuka oleh SQL Server.
FILE_FLAG_WRITE_THROUGH
Memerintahkan sistem untuk menulis melalui cache menengah apa pun dan langsung ke disk. Sistem masih dapat cache tulis operasi, tetapi tidak malas Bersihkan mereka.

Opsi FILE_FLAG_WRITE_THROUGH memastikan bahwa ketika operasi tulis kembali berhasil menyelesaikan, data dengan benar disimpan di penyimpanan stabil. Ini sejalan dengan WAL protokol yang memastikan data.
Banyak kandar cakram (SCSI dan IDE) berisi cache onboard 512 KB, 1 MB, atau lebih besar. Namun, drive cache biasanya bergantung pada kapasitor dan tidak didukung usia baterai solusi. Ini caching mekanisme tidak dapat menjamin penulisan seluruh daya Lingkaran Berkelanjutan atau serupa kegagalan titik. Mereka hanya menjamin menyelesaikan operasi tulis sektor. Ini adalah khusus mengapa log paritas Deteksi dan robek tulis dibangun ke SQL Server 7.0 dan versi yang lebih baru. Drive tetap tumbuh dalam ukuran, cache menjadi lebih besar, dan mereka dapat memasukkan data dalam jumlah besar selama kegagalan.

Banyak vendor peranti penangkap keras menyediakan solusi kontroler disk cadangan usia baterai. Cache controller ini dapat mempertahankan data tembolok selama beberapa hari dan bahkan memungkinkan peranti penangkap keras caching ditempatkan di komputer kedua. Ketika power dengan benar dipulihkan, data yang tertulis sepenuhnya dihapus sebelum diperbolehkan mengakses data lebih lanjut. Banyak yang memungkinkan persentase Baca versus tembolok tulis untuk dibuat untuk kinerja yang optimal. Beberapa berisi area penyimpanan kehabisan memori yang besar. Pada kenyataannya, untuk segmen spesifik pasar, beberapa vendor peranti penangkap keras menyediakan tembolok sistem controller dengan 6 GB cache disk tingkat tinggi cadangan usia baterai. Ini dapat secara signifikan meningkatkan kinerja database.

Lanjut caching penerapan akan menangani permintaan FILE_FLAG_WRITE_THROUGH dengan tidak menonaktifkan tembolok kontroler karena mereka dapat menyediakan true menulis ulang kemampuan sistem reset, kegagalan daya atau titik kegagalan lainnya.

Transfer I/O tanpa menggunakan cache dapat jauh lebih lama karena mekanis waktu yang diperlukan untuk memindahkan kepala drive, putar tarif dan faktor lain yang membatasi.

Memesan sektor

Teknik umum yang digunakan untuk meningkatkan kinerja I/O adalah sektor memesan. Untuk menghindari gerakan kepala mekanis permintaan baca/tulis diurutkan, memungkinkan gerakan lebih konsisten kepala untuk mengambil kembali atau menyimpan data.

Cache dapat menyimpan banyak log dan data menulis permintaan secara bersamaan. Protokol WAL dan implementasi protokol WAL SQL Server memerlukan pembilasan log menulis ke stabil penyimpanan sebelum menulis halaman dapat dikeluarkan. Namun, gunakan cache mungkin kembali keberhasilan dari log menulis permintaan tanpa data ditulis ke pengandar yang sebenarnya (yang, ditulis ke stabil penyimpanan). Hal ini dapat menyebabkan penerbit permintaan tulis halaman data SQL Server.

Dengan keterlibatan tembolok tulis, data tetap dianggap penyimpanan tidak stabil. Namun, dari panggilan Win32 API WriteFile, persis bagaimana SQL Server melihat aktivitas, kode yang dihasilkan berhasil diperoleh. SQL Server atau proses yang menggunakanWriteFileAPI panggilan dapat menentukan onlythat data dengan benar diperoleh penyimpanan stabil.

Untuk tujuan diskusi, misalnya semua sektor dari halaman data diurutkan menulis sebelum sektor catatan log yang cocok. Ini segera melanggar WAL protokol. Cache menulis data halaman sebelum data log. Kecuali cache sepenuhnya didukung usia baterai, kegagalan dapat menyebabkan hasil.

Ketika Anda mengevaluasi faktor kinerja optimal untuk database server, ada banyak faktor untuk mempertimbangkan. Adalah yang paling penting, "Sistem saya mengizinkan valid FILE_FLAG_WRITE_THROUGH kemampuan?"

Catatan Cache apa pun yang sedang Anda usingmust sepenuhnya mendukung solusi cadangan usia baterai. Semua mekanisme caching lainnya yang dugaan kerusakan data dan kehilangan data. SQL Server akan membuat setiap usaha untuk memastikan WAL dengan mengaktifkan FILE_FLAG_WRITE_THROUGH.

Pengujian menunjukkan bahwa banyak konfigurasi kandar mungkin berisi penulisan tembolok tanpa cadangan usia baterai yang sesuai. Drive SCSI, IDE, dan EIDE mengambil manfaat penuh dari penulisan tembolok. Untuk informasi lebih lanjut tentang bagaimana SSD bekerja bersama-sama dengan SQL Server, mendidih berikut CSS SQL Server insinyur Blog artikel:


Dalam banyak konfigurasi, satu-satunya cara untuk dengan benar menonaktifkan tembolok tulis pengandar IDE atau EIDE adalah dengan menggunakan utilitas khusus produsen atau dengan menggunakan jumper terletak di drive itu sendiri. Untuk memastikan bahwa tembolok tulis dinonaktifkan untuk kandar sendiri, hubungi produsen kandar.

Drive SCSI juga memiliki cache tulis. Namun, cache ini biasanya dapat dinonaktifkan oleh sistem operasi. Jika ada pertanyaan, hubungi produsen pengandar untuk utilitas sesuai.

Tulis Cache menumpuk

Menulis Cache menumpuk serupa untuk memesan sektor. Definisi berikut diambil langsung dari terkemuka IDE drive situs web produsen:
Biasanya, mode ini aktif. Menulis mode tembolok menerima host menulis data ke buffer hingga buffer penuh atau host transfer selesai.

Tugas menulis disk dimulai untuk menyimpan data tuan rumah ke cakram. Host menulis perintah terus diterima dan data ditransfer ke buffer hingga baik menulis perintah kehabisan memori penuh atau data buffer penuh. Drive dapat menyusun menulis perintah untuk mengoptimalkan drive volume data.

Otomatis menulis pembahagian (sekarang)

Teknik umum lainnya yang digunakan untuk melindungi data adalah untuk mendeteksi sektor yang rusak selama manipulasi data. Penjelasan berikut ini berasal dari awalan IDE drive situs web produsen:
Fitur ini merupakan bagian dari tembolok tulis dan mengurangi risiko kehilangan data selama operasi tulis ditangguhkan. Jika terjadi galat disk selama proses penulisan disk, disk tugas berhenti dan sektor dicurigai yang dialokasikan kembali ke pool alternatif sektor yang terletak di akhir kandar. Berikut pembahagian, tugas menulis disk terus sampai selesai.
Hal ini dapat fitur kuat jika cadangan usia baterai yang disediakan untuk tembolok. Ini menyediakan sesuai modifikasi saat restart. Lebih baik untuk mendeteksi galat disk, tetapi keamanan data protokol WAL lagi memerlukan ini harus dilakukan waktu nyata dan bukan dalam cara yang ditangguhkan. Dalam parameter WAL, teknik sekarang tidak dapat akun untuk situasi di mana log tulis gagal karena galat sektor tetapi drive penuh. mesin database harus segera tahu tentang kegagalan sehingga transaksi dapat diakhiri dengan benar, administrator dapat diberitahu, dan memperbaiki langkah-langkah yang diambil untuk mengamankan data dan memperbaiki situasi kegagalan media.

Keamanan data

Ada beberapa tindakan yang database administrator harus Anda ambil untuk memastikan keamanan data.
  • Selalu ide yang baik untuk memastikan bahwa strategi cadangan cukup untuk memulihkan dari kegagalan bencana. Penting di luar dan tindakan lain yang sesuai.
  • Uji operasi pemulihan database sekunder atau uji database secara sering.
  • Pastikan bahwa peranti penangkap caching dapat menangani situasi kegagalan semua (listrik, sektor yang rusak, kandar yang rusak, pemutusan sistem, lockups, lonjakan daya, dan sebagainya).
  • Pastikan bahwa peranti penangkap caching:
    • Telah terintegrasi cadangan usia baterai
    • Dapat menulis ulang power-up
    • Dapat sepenuhnya dinonaktifkan jika diperlukan
    • Menangani sektor buruk remapping dalam waktu nyata
  • Aktifkan terpecah deteksi halaman. (Ini sedikit berpengaruh pada kinerja.)
  • Mengkonfigurasi RAID kandar memungkinkan untuk pertukaran panas dari kandar yang buruk, jika memungkinkan.
  • Menggunakan kontroler caching baru yang memungkinkan Anda menambahkan lebih banyak ruang disk tanpa merestart OS. Ini dapat menjadi solusi ideal.

Pengujian kandar

Untuk sepenuhnya mengamankan data Anda, Anda harus memastikan bahwa semua data tembolok dengan benar ditangani. Dalam banyak situasi, Anda harus menonaktifkan tembolok tulis kandar cakram.

Catatan Pastikan bahwa alternatif caching mekanisme dengan benar dapat menangani beberapa jenis kegagalan.

Microsoft telah dilakukan pengujian pada beberapa drive SCSI dan IDE dengan menggunakan utilitas SQLIOSim . Utilitas ini mensimulasikan aktivitas asinkron berat baca/tulis peranti penangkap simulasi data dan log peranti penangkap. Uji kinerja Statistik menunjukkan rata-rata menulis operasi per detik antara 50 dan 70 untuk kandar dengan nonaktif penulisan tembolok dan RPM berkisar antara 5,200 dan 7,200.

Untuk informasi lebih lanjut tentang utilitas SQLIOSim , lihat artikel berikut ini di Pangkalan Pengetahuan Microsoft:
231619 Cara menggunakan utilitas SQLIOSim untuk menirukan aktivitas SQL Server di subsistem cakram
Banyak produsen komputer memesan drive dengan memiliki tembolok tulis dinonaktifkan. Namun, pengujian menunjukkan bahwa hal ini mungkin tidak akan terjadi. Oleh karena itu, selalu menguji sepenuhnya.

peranti penangkap data

Dalam situasi semua tapi tidak dicatat, SQL Server akan memerlukan hanya log data untuk dapat dihapus. Ketika melakukan operasi non-login, halaman data harus juga bersemangat untuk penyimpanan stabil; ada tidak ada catatan log individu membuat kembali tindakan untuk kegagalan.

Halaman data dapat tetap berada di tembolok hingga proses LazyWriter atau CheckPoint flushes mereka untuk penyimpanan stabil. Menggunakan protokol WAL untuk memastikan bahwa data log disimpan dengan benar memastikan bahwa pemulihan dapat memulihkan data halaman ke keadaan yang diketahui.

Ini berarti bahwa dianjurkan untuk menempatkan file data pada kandar cache. Ketika SQL Server flushes halaman data ke stabil penyimpanan, catatan log dapat dipotong dari log transaksi. Jika halaman data yang disimpan di tembolok stabil, dimungkinkan untuk memotong log data yang dapat digunakan untuk memulihkan halaman jika terjadi kegagalan. Pastikan bahwa peranti penangkap data dan log menampung stabil penyimpanan dengan benar.

Meningkatkan kinerja

Pertanyaan pertama yang terjadi adalah: "saya punya IDE kandar yang telah di-cache. Namun ketika saya dinonaktifkan, kinerja saya menjadi sangat kurang dari yang diharapkan. Mengapa?"

Banyak pengandar IDE diuji oleh Microsoft berjalan pada tingkat RPM 5,200, dan SCSI drive rpm 7,200. Ketika Anda menonaktifkan penulisan tembolok pengandar IDE kinerja mekanis dapat menjadi faktor.

Ada area jelas untuk mengatasi perbedaan kinerja: "Alamat tingkat transaksi."

Ada banyak transaksi online (OLTP) sistem yang memerlukan tingkat tinggi transaksi pemrosesan. Untuk sistem ini, pertimbangkan untuk menggunakan kontroler caching yang benar dapat mendukung penulisan tembolok dan menyediakan meningkatkan kinerja sementara memastikan integritas data.

Untuk secara signifikan mengalami perubahan kinerja dengan SQL Server di kandar caching, tingkat transaksi meningkat menggunakan transaksi kecil.

Pengujian menunjukkan bahwa tinggi menulis aktivitas buffer yang kurang dari 512 KB atau lebih besar dari 2 MB dapat menyebabkan kinerja yang lambat.
Pertimbangkan contoh berikut:
CREATE TABLE tblTest ( iID int IDENTITY(1,1), strData char(10))GOSET NOCOUNT ONGOINSERT INTO tblTest VALUES ('Test')WHILE @@IDENTITY < 10000   INSERT INTO tblTest VALUES ('Test')				
Berikut ini adalah contoh hasil uji untuk SQL Server:
SCSI(7200 RPM) 84 detik
SCSI(7200 RPM) 15 detik (Caching controller)

IDE(5200 RPM) 14 detik (Drive cache diaktifkan)
IDE(5200 RPM) 160 detik

Membungkus seluruh rangkaian sisipkan operasi dalam transaksi tunggal berjalan di sekitar empat detik di semua konfigurasi.

Alasan adalah jumlah gejolak log yang diperlukan. Tanpa transaksi, masukkan setiap transaksi dengan sendirinya, dan setiap kali catatan log transaksi harus dihapus. Setiap flush adalah 512 bita ukuran yang membutuhkan intervensi signifikan mekanis kandar.

Ketika transaksi tunggal yang digunakan, catatan log transaksi dapat dibundel dan tulis tunggal, besar dapat digunakan untuk Bersihkan data mengumpulkan log. Intervensi mekanis berkurang secara signifikan.

Peringatan Kami merekomendasikan bahwa Anda tidak meningkatkan jangkauan transaksi Anda. Transaksi berjalan lama dapat menyebabkan berlebihan dan tidak diinginkan memblokir serta meningkatkan atashulu. Gunakan penghitung kinerja SQL Server Database SQL Server: untuk melihat penghitung berbasis log transaksi. Khususnya, Log byte Flushed/sec dapat menunjukkan banyak transaksi kecil yang mengarah ke aktivitas disk mekanis tinggi.

Melihat laporan yang terkait dengan log Kosongkan dan menentukan apabila jumlah gejolak log dapat dikurangi. Dalam contoh sebelumnya, transaksi tunggal diterapkan. Namun, dalam banyak skenario, hal ini dapat menyebabkan perilaku penguncian yang tidak diinginkan. Periksa desain transaksi. Anda dapat menggunakan kode yang mirip berikut ini untuk menjalankan batch untuk mengurangi kegiatan Kosongkan log sering dan kecil:
BEGIN TRANGOINSERT INTO tblTest VALUES ('Test')WHILE @@IDENTITY < 50BEGIN   INSERT INTO tblTest VALUES ('Test')   if(0 = cast(@@IDENTITY as int) % 10)   BEGIN      PRINT 'Commit tran batch'      COMMIT TRAN      BEGIN TRAN   ENDENDGOCOMMIT TRANGO				
SQL Server memerlukan sistem dukungan "dijamin pengiriman ke media yang stabil," sebagaimana dijelaskan di SQL Server I/O keandalan Program Tinjau persyaratan download kumpulan dokumen. Untuk informasi selengkapnya tentang persyaratan input dan output untuk mesin pangkalan data SQL Server, klik nomor artikel berikut ini untuk melihat artikel di Pangkalan Pengetahuan Microsoft:
967576 Microsoft SQL Server Database Engine Input/Output persyaratan

Peringatan: Artikel ini telah diterjemahkan secara otomatis

Properti

ID Artikel: 230785 - Tinjauan Terakhir: 05/17/2015 07:10:00 - Revisi: 3.0

Microsoft SQL Server 2005 Standard Edition, Microsoft SQL Server 2005 Enterprise Edition, Microsoft SQL Server 2005 Developer Edition, Microsoft SQL Server 2005 Workgroup Edition, Microsoft SQL Server 2005 Express Edition, Microsoft SQL Server 2000 Standard Edition, Microsoft SQL Server 7.0 Standard Edition, Microsoft SQL Server 2008 Developer, Microsoft SQL Server 2008 Enterprise, Microsoft SQL Server 2008 Express, Microsoft SQL Server 2008 Standard

  • kbhowto kbinfo kbmt KB230785 KbMtid
Tanggapan
&t=">; document.write("