SQL Server 7.0, SQL Server 2000 dan SQL Server 2005 penebangan dan penyimpanan data algoritma memperpanjang kehandalan data

Terjemahan Artikel Terjemahan Artikel
ID Artikel: 230785 - Melihat produk di mana artikel ini berlaku.
Perbesar semua | Perkecil semua

Pada Halaman ini

RINGKASAN

SQL Server 7.0, SQL Server 2000 dan SQL Server 2005 merestrukturisasi dan mendesain ulang algoritma penebangan dan data dari Microsoft SQL Server rilis yang lebih awal untuk meningkatkan kehandalan data dan integritas.

Untuk mempelajari lebih lanjut tentang konsep-konsep yang mendasari mesin SQL Server 7.0 dan SQL Server 2000, lihat "ARIES (algoritma untuk pemulihan dan isolasi Exploiting semantik): metode transaksi pemulihan pendukung denda-Granularity Locking dan parsial Rollbacks menggunakan menulis-Ahead Logging", ACM transaksi pada sistem Database. Dokumen ini ditulis oleh Chunder Mohan.

Dokumen ini membahas teknik SQL Server 7.0, SQL Server 2000 dan SQL Server 2005 untuk memperpanjang kehandalan data dan integritas yang terkait dengan kegagalan.

Dianjurkan bahwa Anda membaca artikel berikut pada Basis Pengetahuan Microsoft untuk penjelasan lebih lanjut di cache dan alternatif kegagalan modus diskusi:
86903 Deskripsi caching kontroler disk dalam SQL Server
46091 Menggunakan hard disk controller cache dengan SQL Server
234656 Menggunakan cache disk drive dengan SQL Server

INFORMASI LEBIH LANJUT

Sebelum memulai diskusi yang mendalam, beberapa istilah yang digunakan di seluruh artikel ini ditetapkan di bagian berikut.
Perkecil tabel iniPerbesar tabel ini
IstilahDefinisi
Didukung bateraiTerpisah dan lokal baterai cadangan fasilitas langsung tersedia dan dikontrol oleh mekanisme cache untuk mencegah kehilangan data.
Catatan Hal ini tidak uninterruptible power supply (UPS). UPS tidak menjamin kegiatan menulis dan dapat terputus dari perangkat caching.
TembolokMekanisme penyimpanan perantara yang digunakan untuk mengoptimalkan operasi I/O fisik dan meningkatkan kinerja.
Kotor HalamanHalaman yang berisi data modifikasi yang belum memerah untuk penyimpanan stabil. Untuk informasi lebih lanjut mengenai buffer halaman kotor, lihat dokumentasi SQL Server buku Online.
KegagalanApa pun yang mungkin menyebabkan pemadaman tak terduga dari proses SQL Server. Contohnya: power outage, komputer reset, galat memori, lain masalah perangkat keras, bad sector, drive padam, OS kegagalan, dan sebagainya.
FlushMemaksa dari cache buffer untuk stabil penyimpanan.
KaitSinkronisasi objek yang digunakan untuk melindungi konsistensi fisik dari sumber daya.
Penyimpanan bateraiMedia yang tetap tersedia di kegagalan sistem.
Menyematkan HalamanHalaman yang tetap dalam data cache dan tidak bersemangat untuk penyimpanan stabil sampai semua terkait daftar penelepon dijamin di lokasi penyimpanan yang stabil.
Penyimpanan stabilSama seperti baterai penyimpanan.
Penyimpanan tidak stabilMedia yang akan tidak tetap utuh di kegagalan.
SQL Server 2005, SQL Server 2000, SQL Server 7.0, versi sebelumnya dari SQL Server dan database arus utama banyak produk di pasar saat ini menggunakan protokol menulis-Ahead Logging (WAL).

Menulis-Ahead Logging (WAL) protokol

Istilah protokol adalah cara terbaik untuk menggambarkan WAL. Ini adalah tertentu dan ditetapkan seperangkat implementasi langkah-langkah yang diperlukan untuk memastikan data disimpan dan ditukar dengan benar dan dapat dipulihkan untuk negara dikenal dalam hal kegagalan. Sama seperti jaringan berisi sebuah protokol yang didefinisikan untuk bertukar data dengan cara yang konsisten dan dilindungi, begitu juga menggambarkan WAL protokol untuk melindungi data.

ARIES dokumen mendefinisikan WAL sebagai:
Protokol WAL menegaskan bahwa daftar penelepon yang mewakili perubahan untuk beberapa data sudah harus stabil penyimpanan sebelum diubah data diperbolehkan untuk menggantikan versi sebelumnya data dalam penyimpanan baterai. Itu adalah, sistem tidak diperbolehkan untuk menulis halaman diperbarui ke versi baterai penyimpanan halaman sampai setidaknya bagian Batalkan daftar penelepon yang menjelaskan pembaruan ke halaman telah ditulis untuk stabil penyimpanan.
Untuk informasi lebih lanjut tentang menulis-Ahead Logging, lihat dokumentasi SQL Server buku Online.

SQL Server dan WAL

SQL Server 2005, SQL Server 2000, SQL Server 7.0 dan SQL Server rilis yang lebih awal menggunakan protokol WAL. Untuk memastikan committal yang tepat dari transaksi, semua catatan log yang terkait dengan transaksi harus diamankan di penyimpanan stabil.

Untuk memperjelas ini, pertimbangkan contoh berikut khusus (untuk contoh ini berasumsi bahwa indeks dan halaman yang terpengaruh adalah halaman 150).
BEGIN TRANSACTION
   INSERT INTO tblTest VALUES (1)
COMMIT TRANSACTION
				
Sekarang istirahat kegiatan ke langkah-langkah sederhana penebangan:
Perkecil tabel iniPerbesar tabel ini
PernyataanTindakan dilakukan
MULAILAH TRANSAKSIDitulis ke log cache daerah tetapi ada adalah tidak perlu menyiram untuk penyimpanan stabil karena SQL Server tidak membuat perubahan fisik.
Masukkan ke dalam tblTest1. Data halaman 150 diperoleh ke SQL Server data cache, jika tidak sudah tersedia.

2 Halaman. mengunci, terjepit, dan ditandai kotor, dan kunci sesuai yang diperoleh.

3. Sisipkan Log catatan dibuat dan ditambahkan ke log cache.

4. Sebuah baris baru ditambahkan ke halaman data.

5. Selot dirilis.

6. Catatan log yang terkait dengan transaksi atau halaman tidak perlu bersemangat pada titik ini karena semua perubahan tetap berada dalam penyimpanan volatil.
KOMIT TRANSAKSI1. Catatan Log komit terbentuk dan daftar penelepon yang terkait dengan transaksi harus ditulis untuk stabil penyimpanan. Transaksi dianggap tidak berkomitmen sampai daftar penelepon dengan benar ditugaskan untuk penyimpanan stabil.

2. Data halaman 150 tetap dalam SQL Server data cache dan tidak segera memerah untuk penyimpanan stabil. Ketika daftar penelepon benar aman pemulihan dapat mengulang operasi jika diperlukan.

3. Transaksional kunci dirilis.
Jangan bingung dengan mengunci dan penebangan. Meskipun penting, mengunci dan penebangan adalah isu yang terpisah ketika berhadapan dengan WAL. Dalam contoh di atas, SQL Server 7.0, SQL Server 2000 dan SQL Server 2005 umumnya pegang selot pada halaman 150 untuk waktu yang diperlukan untuk melakukan perubahan fisik masukkan pada halaman, tidak seluruh waktu transaksi. Kunci sesuai jenis ditetapkan untuk melindungi baris, kisaran, halaman, atau meja yang diperlukan. Lihat bagian penguncian SQL Server buku Online untuk detail lebih lanjut tentang jenis kunci.

Melihat contoh secara lebih rinci, Anda mungkin bertanya apa yang terjadi ketika LazyWriter atau CheckPoint proses mengeksekusi. SQL Server 7.0, SQL Server 2000 dan SQL Server 2005 isu semua flushes sesuai untuk stabil penyimpanan untuk transaksional daftar penelepon berhubungan dengan kotor dan menyematkan halaman. Hal ini menjamin protokol WAL halaman data dapat tidak pernah ditulis untuk stabil penyimpanan sampai terkait transaksional daftar penelepon memerah.

SQL Server dan stabil penyimpanan

SQL Server 7.0, SQL Server 2000 dan SQL Server 2005 meningkatkan data log dan halaman operasi oleh termasuk pengetahuan disk sektor ukuran (umumnya 512 byte).

Untuk mempertahankan sifat-sifat asam transaksi, SQL Server harus memperhitungkan kegagalan poin. Selama kegagalan banyak disk drive spesifikasi hanya menjamin sejumlah sektor menulis operasi. Kebanyakan spesifikasi menjamin selesai menulis satu sektor ketika terjadi kegagalan.

SQL Server 7.0, SQL Server 2000 dan SQL Server 2005 menggunakan halaman 8 KB data dan log (jika memerah) di kelipatan dari ukuran sektor. (Kebanyakan disk drive menggunakan 512 byte sebagai ukuran sektor default.) Dari kegagalan, SQL Server dapat memperhitungkan menulis operasi lebih besar daripada sektor dengan menggunakan log paritas dan teknik menulis robek.

Halaman robek deteksi

Bagian berikut berasal dari SQL Server 7.0 buku Online menggambarkan deteksi robek halaman:
Pilihan ini memungkinkan SQL Server untuk mendeteksi lengkap operasi I/O yang disebabkan oleh kegagalan daya atau sistem lain padam. Ketika benar, menyebabkan sedikit untuk membalik untuk masing-masing 512-byte sektor dalam 8-Kilobita (KB) database halaman setiap kali halaman ditulis ke disk. Jika sedikit di negara salah ketika halaman kemudian dibaca oleh SQL Server, kemudian halaman ditulis salah; Halaman robek terdeteksi. Halaman robek biasanya terdeteksi selama pemulihan karena setiap halaman yang ditulis secara tidak benar mungkin untuk dibaca oleh pemulihan.

Meskipun SQL Server database halaman 8 KB, disk melakukan operasi I/O menggunakan 512-byte sektor. Oleh karena itu, sektor 16 ditulis per halaman database. Halaman robek dapat terjadi jika sistem gagal (misalnya, karena kegagalan daya) antara saat sistem operasi menulis sektor 512-byte pertama ke disk dan penyelesaian 8 KB I/O operasi. Jika sektor pertama Halaman database berhasil ditulis sebelum kegagalan, halaman database pada disk akan muncul sebagai diperbarui, meskipun itu mungkin tidak berhasil.

Menggunakan baterai-didukung disk controller cache dapat memastikan bahwa data berhasil ditulis ke disk atau tidak ditulis sama sekali. Dalam kasus ini, tidak menetapkan halaman robek deteksi untuk benar, untuk tidak diperlukan.
Catatan Halaman robek deteksi tidak diaktifkan secara default dalam SQL Server 7.0. Lihat sp_dboption bagaimana untuk mengaktifkan deteksi pada sistem Anda.

Log paritas

Log parity check sangat mirip dengan deteksi robek halaman. Masing-masing 512-byte sektor berisi parity bit. Parity bit ini selalu ditulis dengan rekaman log dan dievaluasi ketika rekaman log diperoleh. Dengan memaksa log menulis pada batas 512-byte, SQL Server 7.0, SQL Server 2000 dan SQL Server 2005 dapat memastikan bahwa operasi committal benar-benar ditulis untuk sektor disk fisik.

Perubahan memberikan peningkatan data konsistensi, bahkan melalui sebelum Versi SQL Server.

Versi SQL Server lebih awal dari 7.0

Versi SQL Server sebelumnya daripada 7,0 tidak memberikan log paritas atau robek sedikit deteksi fasilitas. Bahkan, versi tersebut dapat menulis halaman log yang sama beberapa kali sampai daftar penelepon mengisi halaman 2-KB log. Ini dapat mengekspos transaksi yang telah berhasil melakukan. Jika halaman log ditulis ulang selama kegagalan, sektor dengan transaksi berkomitmen mungkin tidak mendapatkan ulang dengan benar.

Dampak kinerja

Semua versi SQL Server membuka file log dan data yang menggunakan Win32 CreateFile fungsi. The dwFlagsAndAttributes anggota meliputi FILE_FLAG_WRITE_THROUGH pilihan ketika dibuka oleh SQL Server.
FILE_FLAG_WRITE_THROUGH
Memerintahkan sistem untuk menulis melalui cache setiap menengah dan pergi langsung ke disk. Sistem dapat masih cache menulis operasi, tetapi tidak malas menyiram mereka.

Pilihan FILE_FLAG_WRITE_THROUGH memastikan bahwa ketika menulis operasi kembali berhasil menyelesaikan data dengan benar disimpan dalam penyimpanan stabil. Ini sejalan dengan protokol WAL memastikan data.
Banyak disk drive (SCSI dan IDE) berisi onboard cache 512 KB, 1 MB, atau lebih besar. Namun, drive cache biasanya bergantung pada sebuah kapasitor dan tidak didukung baterai solusi. Ini caching mekanisme tidak dapat menjamin menulis di kekuasaan siklus atau kegagalan serupa titik. Mereka hanya menjamin selesai menulis sektor operasi. Ini adalah khusus mengapa menulis robek dan log paritas deteksi dibangun ke SQL Server 7.0, SQL Server 2000 dan SQL Server 2005. Sebagai drive terus tumbuh dalam ukuran, cache menjadi lebih besar, dan mereka dapat mengekspos data dalam jumlah besar selama kegagalan.

Banyak vendor perangkat keras menyediakan didukung baterai disk controller solusi. Cache controller ini dapat mempertahankan data dalam cache selama beberapa hari dan bahkan memungkinkan hardware caching untuk ditempatkan di komputer kedua. Ketika kekuatan benar dipulihkan, data tidak tertulis adalah benar-benar memerah sebelum mengakses data lebih lanjut diperbolehkan. Banyak dari mereka memungkinkan persentase baca versus menulis cache untuk ditetapkan untuk kinerja optimal. Beberapa berisi area penyimpanan memori yang besar. Bahkan, untuk sangat spesifik segmen pasar, beberapa vendor perangkat keras menyediakan high-end didukung baterai perangkat cache sistem controller dengan 6 GB dari cache. Ini dapat secara signifikan meningkatkan database kinerja.

Lanjutan caching implementasi akan menangani FILE_FLAG_WRITE_THROUGH permintaan dengan tidak menonaktifkan controller cache karena mereka dapat memberikan kemampuan menulis ulang yang benar dalam hal sistem reset, kegagalan daya atau titik kegagalan lain.

Transfer I/O tanpa menggunakan cache dapat secara signifikan lebih lama karena untuk waktu mekanis yang dibutuhkan untuk menggerakkan kepala drive, spin harga, dan faktor-faktor lain yang membatasi.

Sektor memesan

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

Cache dapat menyimpan beberapa log dan data menulis permintaan pada waktu yang sama. Protokol WAL dan pelaksanaan SQL Server protokol WAL memerlukan pembilasan log menulis untuk stabil penyimpanan sebelum menulis halaman dapat dikeluarkan. Namun, penggunaan cache mungkin kembali sukses dari permintaan menulis log tanpa data yang ditulis ke drive sebenarnya (yang, ditulis untuk stabil penyimpanan). Hal ini dapat mengakibatkan SQL Server mengeluarkan permintaan menulis halaman data.

Dengan menulis cache keterlibatan, data masih dianggap dalam penyimpanan volatil. Namun, dari Win32 API WriteFile panggilan, persis bagaimana SQL Server melihat aktivitas, kode kembali berhasil diperoleh. SQL Server atau proses menggunakan WriteFile API panggilan hanya dapat mendeduksikan data dengan benar telah memperoleh stabil penyimpanan.

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

Ketika mengevaluasi faktor kinerja optimal untuk database server, ada banyak faktor untuk mempertimbangkan. Terutama pertimbangan ini adalah "Apakah sistem saya memungkinkan kemampuan FILE_FLAG_WRITE_THROUGH berlaku?"

Catatan Setiap cache Anda menggunakan harus dukungan penuh solusi didukung baterai. Semua mekanisme caching adalah tersangka korupsi data dan kehilangan data. SQL Server membuat setiap usaha untuk memastikan WAL dengan memungkinkan FILE_FLAG_WRITE_THROUGH.

Pengujian telah menunjukkan bahwa banyak konfigurasi disk drive mungkin mengandung menulis cache tanpa tepat baterai cadangan. Drive SCSI, IDE, dan EIDE mengambil keuntungan penuh dari menulis cache.

Dalam banyak konfigurasi, satu-satunya cara untuk benar menonaktifkan caching menulis IDE atau EIDE drive adalah dengan utilitas produsen tertentu atau dengan menggunakan jumper terletak di drive itu sendiri. Untuk memastikan bahwa cache menulis dinonaktifkan untuk drive itu sendiri, hubungi pabrik pengandar.

SCSI drive juga memiliki cache menulis tapi cache ini umumnya dapat dinonaktifkan oleh sistem operasi. Jika ada pertanyaan, hubungi pabrik pengandar untuk utilitas yang sesuai.

Menulis Cache susun

Menulis Cache susun mirip dengan sektor memesan. Definisi berikut ini diambil langsung dari drive IDE terkemuka produsen situs Web:
Biasanya, mode ini aktif. Menulis modus cache menerima host menulis data ke buffer sampai buffer penuh atau host transfer selesai.

Tugas menulis disk dimulai untuk menyimpan data host ke disk. Tuan rumah menulis perintah terus diterima dan data ditransfer ke buffer sampai baik menulis perintah tumpukan penuh atau data buffer penuh. Drive dapat menyusun ulang menulis perintah untuk mengoptimalkan drive throughput.

Otomatis menulis realokasi (AWR)

Lain teknik umum yang digunakan untuk melindungi data adalah untuk mendeteksi bad sector selama manipulasi data. Penjelasan berikut berasal dari terkemuka IDE drive produsen situs Web yang sama:
Fitur ini merupakan bagian dari cache menulis dan mengurangi resiko kehilangan data selama operasi ditangguhkan menulis. Dialokasikan jika disk error terjadi selama proses menulis disk, disk tugas berhenti dan sektor tersangka adalah kembali ke kolam sektor alternatif yang terletak di ujung drive. Setelah realokasi, tugas menulis disk terus sampai selesai.
Ini bisa menjadi fitur yang sangat kuat jika baterai cadangan yang disediakan untuk cache, sehingga modifikasi yang tepat saat restart. Lebih disukai untuk mendeteksi disk error, tapi keamanan data protokol WAL lagi akan memerlukan ini dilaksanakan secara real time dan bukan dalam cara yang ditangguhkan. Dalam parameter WAL, teknik AWR tidak dapat menjelaskan situasi di mana menulis log gagal karena kesalahan sektor tetapi drive penuh. Mesin database harus segera tahu tentang kegagalan sehingga transaksi dapat benar dibatalkan, administrator dapat diberitahu, dan langkah-langkah yang tepat diambil untuk mengamankan data dan memperbaiki situasi kegagalan media.

Data keselamatan

Ada beberapa tindakan pencegahan yang database administrator harus mengambil untuk memastikan keamanan data.
  • Itu adalah selalu ide yang baik untuk memastikan bahwa strategi backup Anda sudah cukup untuk pulih dari kegagalan bencana. Offsite penyimpanan dan tindakan pencegahan lainnya yang sesuai.
  • Menguji operasi pemulihan database dalam sekunder atau tes database pada dasar sering.
  • Memastikan bahwa perangkat caching dapat menangani semua kegagalan situasi (listrik, bad sector, buruk drive, sistem listrik, lockups, kekuatan spike, dan sebagainya).
  • Pastikan bahwa perangkat cache:
    • Telah terintegrasi baterai cadangan.
    • Dapat ulang menulis pada kekuasaan.
    • Dapat sepenuhnya dinonaktifkan jika diperlukan.
    • Menangani sektor buruk re-mapping realtime.
  • Aktifkan robek halaman deteksi; memiliki sedikit dampak kinerja.
  • Mengkonfigurasi drive RAID memungkinkan untuk swap panas disk drive yang buruk, jika mungkin.
  • Menggunakan kontroler caching baru yang memungkinkan penambahan lebih banyak ruang disk tanpa merestart OS. Ini bisa menjadi solusi ideal.

Menguji drive

Untuk sepenuhnya mengamankan data Anda, Anda harus memastikan bahwa semua data cache benar ditangani. Dalam banyak situasi, ini berarti Anda harus menonaktifkan caching tulis disk drive.

Catatan Memastikan bahwa mekanisme cache alternatif dapat menangani beberapa jenis kegagalan.

Microsoft telah melakukan pengujian pada beberapa drive SCSI dan IDE menggunakan SQLIOStress utilitas. Utilitas ini mensimulasikan berat asynchronous baca/tulis kegiatan untuk perangkat simulasi data dan log perangkat. Tes kinerja statistik menunjukkan rata-rata menulis operasi per detik antara 50 dan 70 untuk drive dengan cacat menulis cache dan RPM berkisar antara 5,200 dan 7,200.

Untuk informasi lebih lanjut dan rincian tentang SQLIOStress utilitas, lihat artikel berikut pada Basis Pengetahuan Microsoft:
231619 Cara menggunakan utilitas SQLIOStress untuk stres subsistem disk seperti SQL Server
Banyak produsen PC (misalnya, Compaq, Dell, Gateway, HP, dan sebagainya) memesan drive dengan cache menulis yang dinonaktifkan. Namun, pengujian menunjukkan bahwa ini mungkin tidak selalu menjadi kasus jadi selalu menguji sepenuhnya.

Perangkat data

Dalam semua tapi non-log situasi, SQL Server akan memerlukan hanya daftar penelepon akan memerah. Ketika melakukan operasi non-login, halaman data harus juga bersemangat untuk penyimpanan stabil; ada tidak ada catatan log individu untuk meregenerasi tindakan dari kegagalan.

Halaman data dapat tetap dalam cache sampai proses LazyWriter atau CheckPoint flushes mereka untuk penyimpanan stabil. Menggunakan protokol WAL untuk memastikan bahwa daftar penelepon benar disimpan memastikan bahwa pemulihan dapat memulihkan data halaman untuk sebuah negara yang dikenal.

Ini tidak berarti bahwa dianjurkan untuk menempatkan file data pada drive cache. Ketika SQL Server flushes halaman data ke penyimpanan yang stabil, catatan log dapat dipotong dari log transaksi. Jika halaman data disimpan di cache tidak stabil, dimungkinkan untuk memotong daftar penelepon yang akan digunakan untuk memulihkan halaman dalam hal kegagalan. Memastikan bahwa data dan log perangkat mengakomodasi penyimpanan stabil dengan benar.

Meningkatkan kinerja

Pertanyaan awal yang muncul adalah: "saya memiliki drive IDE yang adalah caching tetapi ketika saya dinonaktifkan itu, kinerja saya menjadi secara signifikan kurang dari diharapkan - mengapa?"

Banyak IDE drive diuji oleh Microsoft menjalankan laju RPM 5,200, dan SCSI drive pada RPM 7,200. Bila Anda menonaktifkan menulis caching IDE drive kinerja mekanis dapat menjadi faktor.

Ada daerah yang sangat jelas untuk mengatasi perbedaan kinerja: "Alamat rate transaksi."

Ada banyak transaksi online processing (OLTP) sistem yang memerlukan tingkat tinggi transaksi. Untuk sistem ini, pertimbangkan untuk menggunakan pengendali cache yang benar dapat mendukung cache menulis dan memberikan dorongan kinerja sambil memastikan integritas data.

Untuk secara signifikan menghadapi perubahan performa dengan SQL Server pada caching drive, tingkat transaksi meningkat menggunakan transaksi kecil.

Pengujian menunjukkan bahwa aktivitas tinggi menulis buffer yang lebih kecil dari 512 KB atau di atas 2 MB dapat menyebabkan kinerja lambat.
Perhatikan contoh berikut:
CREATE TABLE tblTest ( iID int IDENTITY(1,1), strData char(10))
GO

SET NOCOUNT ON
GO

INSERT INTO tblTest VALUES ('Test')
WHILE @@IDENTITY < 10000
   INSERT INTO tblTest VALUES ('Test')
				
Berikut ini adalah contoh hasil tes 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 seri seluruh operasi INSERT dalam transaksi tunggal berjalan di sekitar 4 detik di semua konfigurasi.

Alasannya adalah jumlah log flushes diperlukan. Tanpa transaksi, masukkan setiap adalah transaksi dalam dan dari dirinya sendiri, dan setiap kali daftar penelepon untuk transaksi harus memerah. Masing-masing adalah 512 byte dalam ukuran, yang memerlukan intervensi signifikan mekanis drive.

Ketika transaksi tunggal digunakan, daftar penelepon untuk transaksi dapat digabungkan dan menulis satu, lebih besar dapat digunakan untuk flush berkumpul daftar penelepon. Intervensi mekanis secara signifikan dikurangi.

Warning Hal ini tidak dianjurkan bahwa Anda meningkatkan cakupan transaksi Anda. Transaksi berjalan lama dapat mengakibatkan berlebihan dan tidak diinginkan menghalangi serta meningkatkan overhead. Menggunakan penghitung kinerja SQL Server 7.0, SQL Server 2000 dan SQL Server 2005 SQL Server: database untuk melihat Counter berbasis log transaksi. Secara khusus, Log byte memerah/sec dapat menunjukkan banyak transaksi kecil yang mengarah ke aktivitas tinggi mekanis disk.

Melihat laporan yang terkait dengan log memerah dan menentukan jika jumlah log flushes dapat berkurang. Dalam contoh di atas, transaksi tunggal dilaksanakan. Namun, dalam banyak skenario ini dapat menyebabkan perilaku penguncian yang tidak dikehendaki. Melihat desain transaksi. Mungkin sesuatu seperti berikut untuk menjalankan batch untuk mengurangi sering dan kecil log menyiram kegiatan:
BEGIN TRAN
GO

INSERT INTO tblTest VALUES ('Test')
WHILE @@IDENTITY < 50
BEGIN
   INSERT INTO tblTest VALUES ('Test')

   if(0 = cast(@@IDENTITY as int) % 10)
   BEGIN
      PRINT 'Commit tran batch'
      COMMIT TRAN
      BEGIN TRAN
   END
END
GO

COMMIT TRAN
GO
				
SQL Server 6.x mungkin tidak melihat dampak kinerja yang sama dari menulis log transaksi sering dan kecil. SQL Server 6.x penulisan ulang halaman 2-KB log yang sama seperti transaksi dilakukan. Ini dapat mengurangi ukuran log secara signifikan dibandingkan dengan 512-byte sektor batas flushes SQL Server 7.0, SQL Server 2000 dan SQL Server 2005. Mengurangi ukuran log secara langsung berhubungan dengan jumlah mekanis drive aktivitas. Namun, seperti dijelaskan di atas, SQL Server 6.x algoritma dapat mengungkap berkomitmen transaksi.
SQL Server memerlukan sistem untuk mendukung 'pengiriman dijamin stabil media' seperti diuraikan di bawah program Microsoft SQL Server Always-On penyimpanan solusi Review. FoUntuk informasi lebih lanjut tentang persyaratan input dan output untuk mesin database SQL Server, klik nomor artikel di bawah ini untuk melihat artikel di dalam Basis Pengetahuan Microsoft:
967576Microsoft SQL Server Database Engine Input/Output persyaratan

Properti

ID Artikel: 230785 - Kajian Terakhir: 19 September 2011 - Revisi: 2.0
Berlaku bagi:
  • 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
Kata kunci: 
kbhowto kbinfo kbmt KB230785 KbMtid
Penerjemahan Mesin
PENTING: Artikel ini diterjemahkan menggunakan perangkat lunak mesin penerjemah Microsoft dan bukan oleh seorang penerjemah. Microsoft menawarkan artikel yang diterjemahkan oleh seorang penerjemah maupun artikel yang diterjemahkan menggunakan mesin sehingga Anda akan memiliki akses ke seluruh artikel baru yang diterbitkan di Pangkalan Pengetahuan (Knowledge Base) dalam bahasa yang Anda gunakan. Namun, artikel yang diterjemahkan menggunakan mesin tidak selalu sempurna. Artikel tersebut mungkin memiliki kesalahan kosa kata, sintaksis, atau tata bahasa, hampir sama seperti orang asing yang berbicara dalam bahasa Anda. Microsoft tidak bertanggung jawab terhadap akurasi, kesalahan atau kerusakan yang disebabkan karena kesalahan penerjemahan konten atau penggunaannya oleh para pelanggan. Microsoft juga sering memperbarui perangkat lunak mesin penerjemah.
Klik disini untuk melihat versi Inggris dari artikel ini:230785

Berikan Masukan

 

Contact us for more help

Contact us for more help
Connect with Answer Desk for expert help.
Get more support from smallbusiness.support.microsoft.com